[jira] [Updated] (SYNCOPE-503) Workflow for Roles
[ https://issues.apache.org/jira/browse/SYNCOPE-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated SYNCOPE-503: --- Description: For SYNCOPE-173 my understanding is that currently there is no plan to apply same workflow concepts of users to role as there are no real use case. Our requirement requires a "maker/checker" functionality not just for users but for roles as well (even configuration, reports, tasks). We were able to configure this functionality on user create/update but not in role. For our User use case, for any users created in Role A requires approval from some Role X. We would like to request to apply same Activiti concept to Roles management as well. Example use case would be to apply maker/checker functionality when creating roles, assigning users to roles and assigning entitlements to roles. was: For JIRA-173 my understanding is that currently there is no plan to apply same workflow concepts of users to role as there are no real use case. Our requirement requires a "maker/checker" functionality not just for users but for roles as well (even configuration, reports, tasks). We were able to configure this functionality on user create/update but not in role. For our User use case, for any users created in Role A requires approval from some Role X. We would like to request to apply same Activiti concept to Roles management as well. Example use case would be to apply maker/checker functionality when creating roles, assigning users to roles and assigning entitlements to roles. > Workflow for Roles > -- > > Key: SYNCOPE-503 > URL: https://issues.apache.org/jira/browse/SYNCOPE-503 > Project: Syncope > Issue Type: New Feature > Components: core >Affects Versions: 1.1.7 > Environment: >Reporter: Quirino A. Gervacio Jr. > > For SYNCOPE-173 my understanding is that currently there is no plan to apply > same workflow concepts of users to role as there are no real use case. > Our requirement requires a "maker/checker" functionality not just for users > but for roles as well (even configuration, reports, tasks). We were able to > configure this functionality on user create/update but not in role. > For our User use case, for any users created in Role A requires approval from > some Role X. > We would like to request to apply same Activiti concept to Roles management > as well. Example use case would be to apply maker/checker functionality when > creating roles, assigning users to roles and assigning entitlements to roles. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (SYNCOPE-503) Workflow for Roles
Quirino A. Gervacio Jr. created SYNCOPE-503: --- Summary: Workflow for Roles Key: SYNCOPE-503 URL: https://issues.apache.org/jira/browse/SYNCOPE-503 Project: Syncope Issue Type: New Feature Components: core Affects Versions: 1.1.7 Environment: Reporter: Quirino A. Gervacio Jr. For JIRA-173 my understanding is that currently there is no plan to apply same workflow concepts of users to role as there are no real use case. Our requirement requires a "maker/checker" functionality not just for users but for roles as well (even configuration, reports, tasks). We were able to configure this functionality on user create/update but not in role. For our User use case, for any users created in Role A requires approval from some Role X. We would like to request to apply same Activiti concept to Roles management as well. Example use case would be to apply maker/checker functionality when creating roles, assigning users to roles and assigning entitlements to roles. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026427#comment-14026427
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Sounds good!
Colm.
> Support synchronizing non-cleartext passwords from external resources
> -
>
> Key: SYNCOPE-313
> URL: https://issues.apache.org/jira/browse/SYNCOPE-313
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Currently we can synchronize cleartext passwords from external resources.
> However, we can't handle non-cleartext passwords, as they get treated as if
> they are plaintext passwords when imported into Syncope, and hence hashed
> again according to user.cipherAlgorithm().
> This task is to treat an imported password as hashed according to a give
> cipher algorithm configured on the connector (for example via 'Password
> Cipher Algorithm' for the DB Connector).
> This is specific to each individual connector, as for example for the DB
> Connector, it might just be a hashed value stored in a table, whereas for
> LDAP it'll be of the form "CIPHER}VALUE" etc.
> Note that we we cannot refer to any specific connector bundle from inside the
> SyncopeSyncResultHandler, hence we should find the cleanest place to
> encapsulate the following logic:
> if (password.isClearText()) {
> // do as currently done
> } else {
> if (connector.isLDAP()) {
>// extract cipher and value
> } else if (connector.isDBTable()) {
>// treat value as ciphered with the cipher defined in connector
> configuration
> } else {
> ...
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026425#comment-14026425
]
Francesco Chicchiriccò commented on SYNCOPE-313:
Almost :-)
I would only change c) to
{{DBPasswordSynchronizationAction}} will be designed to work with a database.
It just stores the encoded password directly into {{SyncopeUser}}, with the
presumption that the password is encoded in HEX in the database + hashed via
the algorithm configured in the ""Password cipher algorithm" parameter of the
underlying connector instance (this might be different from internal storage's
{{password.cipher.algorithm}}).
> Support synchronizing non-cleartext passwords from external resources
> -
>
> Key: SYNCOPE-313
> URL: https://issues.apache.org/jira/browse/SYNCOPE-313
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Currently we can synchronize cleartext passwords from external resources.
> However, we can't handle non-cleartext passwords, as they get treated as if
> they are plaintext passwords when imported into Syncope, and hence hashed
> again according to user.cipherAlgorithm().
> This task is to treat an imported password as hashed according to a give
> cipher algorithm configured on the connector (for example via 'Password
> Cipher Algorithm' for the DB Connector).
> This is specific to each individual connector, as for example for the DB
> Connector, it might just be a hashed value stored in a table, whereas for
> LDAP it'll be of the form "CIPHER}VALUE" etc.
> Note that we we cannot refer to any specific connector bundle from inside the
> SyncopeSyncResultHandler, hence we should find the cleanest place to
> encapsulate the following logic:
> if (password.isClearText()) {
> // do as currently done
> } else {
> if (connector.isLDAP()) {
>// extract cipher and value
> } else if (connector.isDBTable()) {
>// treat value as ciphered with the cipher defined in connector
> configuration
> } else {
> ...
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026419#comment-14026419
]
Colm O hEigeartaigh edited comment on SYNCOPE-313 at 6/10/14 1:14 PM:
--
Yep I think we are in agreement. So to summarise:
a) We will add the ability to synchronize non-cleartext passwords via a
Synchronization Task action class.
b) LDAPPasswordSyncActions will be designed to work with LDAP. If the password
is of the form "{SHA}XYZ", it will check that the digest algorithm is
supported, and if so it will BASE-64 decode the password, HEX-encode the
result, and store it directly into SyncopeUser. If the password is not of the
form "{SHA}XYZ", then it just handles it via the PasswordEncoder as per normal.
c) DBPasswordSynchronizationAction will be designed to work with a database. It
just stores the encoded password directly into SyncopeUser, with the
presumption that the password is encoded in HEX in the database + hashed via
the same algorithm configured for Syncope under password.cipher.algorithm.
d) SYNCOPE-502 will provider for chaining multiple action classes together if
required.
Does this cover it?
Colm.
was (Author: coheigea):
Yep I think we are in agreement. So to summarise:
a) We will add the ability to synchronize non-cleartext passwords via a
Synchronization Task action class.
b) LDAPPasswordSyncActions will be designed to work with LDAP. If the password
is of the form "{SHA}XYZ", it will check that the digest algorithm is
supported, and if so it will BASE-64 decode the password, HEX-encode the
result, and store it directly into SyncopeUser. If the password is not of the
form "{SHA}XYZ", then it just handles it via the PasswordEncoder as per normal.
c) DBPasswordSynchronizationAction will be designed to work with a database. It
just stores the encoded password directly into SyncopeUser, with the
presumption that the password is encoded in HEX in the database + hashed via
the same algorithm configured for Syncope under password.cipher.algorithm.
Does this cover it?
Colm.
b) SYNCOPE-502
> Support synchronizing non-cleartext passwords from external resources
> -
>
> Key: SYNCOPE-313
> URL: https://issues.apache.org/jira/browse/SYNCOPE-313
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Currently we can synchronize cleartext passwords from external resources.
> However, we can't handle non-cleartext passwords, as they get treated as if
> they are plaintext passwords when imported into Syncope, and hence hashed
> again according to user.cipherAlgorithm().
> This task is to treat an imported password as hashed according to a give
> cipher algorithm configured on the connector (for example via 'Password
> Cipher Algorithm' for the DB Connector).
> This is specific to each individual connector, as for example for the DB
> Connector, it might just be a hashed value stored in a table, whereas for
> LDAP it'll be of the form "CIPHER}VALUE" etc.
> Note that we we cannot refer to any specific connector bundle from inside the
> SyncopeSyncResultHandler, hence we should find the cleanest place to
> encapsulate the following logic:
> if (password.isClearText()) {
> // do as currently done
> } else {
> if (connector.isLDAP()) {
>// extract cipher and value
> } else if (connector.isDBTable()) {
>// treat value as ciphered with the cipher defined in connector
> configuration
> } else {
> ...
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026419#comment-14026419
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Yep I think we are in agreement. So to summarise:
a) We will add the ability to synchronize non-cleartext passwords via a
Synchronization Task action class.
b) LDAPPasswordSyncActions will be designed to work with LDAP. If the password
is of the form "{SHA}XYZ", it will check that the digest algorithm is
supported, and if so it will BASE-64 decode the password, HEX-encode the
result, and store it directly into SyncopeUser. If the password is not of the
form "{SHA}XYZ", then it just handles it via the PasswordEncoder as per normal.
c) DBPasswordSynchronizationAction will be designed to work with a database. It
just stores the encoded password directly into SyncopeUser, with the
presumption that the password is encoded in HEX in the database + hashed via
the same algorithm configured for Syncope under password.cipher.algorithm.
Does this cover it?
Colm.
b) SYNCOPE-502
> Support synchronizing non-cleartext passwords from external resources
> -
>
> Key: SYNCOPE-313
> URL: https://issues.apache.org/jira/browse/SYNCOPE-313
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Currently we can synchronize cleartext passwords from external resources.
> However, we can't handle non-cleartext passwords, as they get treated as if
> they are plaintext passwords when imported into Syncope, and hence hashed
> again according to user.cipherAlgorithm().
> This task is to treat an imported password as hashed according to a give
> cipher algorithm configured on the connector (for example via 'Password
> Cipher Algorithm' for the DB Connector).
> This is specific to each individual connector, as for example for the DB
> Connector, it might just be a hashed value stored in a table, whereas for
> LDAP it'll be of the form "CIPHER}VALUE" etc.
> Note that we we cannot refer to any specific connector bundle from inside the
> SyncopeSyncResultHandler, hence we should find the cleanest place to
> encapsulate the following logic:
> if (password.isClearText()) {
> // do as currently done
> } else {
> if (connector.isLDAP()) {
>// extract cipher and value
> } else if (connector.isDBTable()) {
>// treat value as ciphered with the cipher defined in connector
> configuration
> } else {
> ...
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026409#comment-14026409
]
Francesco Chicchiriccò commented on SYNCOPE-313:
It seems that both the internal storage and also external databases (see the
MySQL sample above) are using HEX while only LDAP is using BASE64 (and thus
{{LDAPPasswordSyncActions}} will need to handle digest encoding).
If you change the internal storage to BASE64 you will end up in a similar
situation where internal storage and LDAP are using BASE64 and external
databases HEX (and thus {{DBPasswordSynchronizationAction}} will need to handle
digest encoding).
If this is correct, I would personally leave HEX for internal - to ease
migration from 1_1_X.
> Support synchronizing non-cleartext passwords from external resources
> -
>
> Key: SYNCOPE-313
> URL: https://issues.apache.org/jira/browse/SYNCOPE-313
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Currently we can synchronize cleartext passwords from external resources.
> However, we can't handle non-cleartext passwords, as they get treated as if
> they are plaintext passwords when imported into Syncope, and hence hashed
> again according to user.cipherAlgorithm().
> This task is to treat an imported password as hashed according to a give
> cipher algorithm configured on the connector (for example via 'Password
> Cipher Algorithm' for the DB Connector).
> This is specific to each individual connector, as for example for the DB
> Connector, it might just be a hashed value stored in a table, whereas for
> LDAP it'll be of the form "CIPHER}VALUE" etc.
> Note that we we cannot refer to any specific connector bundle from inside the
> SyncopeSyncResultHandler, hence we should find the cleanest place to
> encapsulate the following logic:
> if (password.isClearText()) {
> // do as currently done
> } else {
> if (connector.isLDAP()) {
>// extract cipher and value
> } else if (connector.isDBTable()) {
>// treat value as ciphered with the cipher defined in connector
> configuration
> } else {
> ...
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026407#comment-14026407
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Ok so what you are proposing is that we BASE-64 decode the encoded password in
LDAPPasswordSyncAction, and then HEX encode it + store it in SyncopeUser? Yes I
think this will work fine. The only issue is that it seems a bit unwieldy to
have separate Sync Actions just to support different encoding behaviours. I
guess we could just default to assuming the passwords are BASE-64 encoded in
the backend for now.
Colm.
> Support synchronizing non-cleartext passwords from external resources
> -
>
> Key: SYNCOPE-313
> URL: https://issues.apache.org/jira/browse/SYNCOPE-313
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Currently we can synchronize cleartext passwords from external resources.
> However, we can't handle non-cleartext passwords, as they get treated as if
> they are plaintext passwords when imported into Syncope, and hence hashed
> again according to user.cipherAlgorithm().
> This task is to treat an imported password as hashed according to a give
> cipher algorithm configured on the connector (for example via 'Password
> Cipher Algorithm' for the DB Connector).
> This is specific to each individual connector, as for example for the DB
> Connector, it might just be a hashed value stored in a table, whereas for
> LDAP it'll be of the form "CIPHER}VALUE" etc.
> Note that we we cannot refer to any specific connector bundle from inside the
> SyncopeSyncResultHandler, hence we should find the cleanest place to
> encapsulate the following logic:
> if (password.isClearText()) {
> // do as currently done
> } else {
> if (connector.isLDAP()) {
>// extract cipher and value
> } else if (connector.isDBTable()) {
>// treat value as ciphered with the cipher defined in connector
> configuration
> } else {
> ...
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026394#comment-14026394
]
Francesco Chicchiriccò commented on SYNCOPE-313:
After some reference tests with {{-Pdebug}} I think I've finally got your point.
When I create an user via {{ldapadd}} with password 'password', the actual
value using {{SHA1}} is
{code}
{SSHA}nuCQ3hYajf2HUcfdIUj48C5eqA7x94ks
{code}
hence it is safe to assume that a similar value will be returned by the LDAP
connector.
However, on Syncope's internal storage, the same password value ('password')
encrypted using {{SHA1}} results in
{code}
5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
{code}
which is the same value - apart from letter case - returned, for example, by
internal MySQL function:
{code}
mysql> select sha1('password');
+--+
| sha1('password') |
+--+
| 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 |
+--+
{code}
and also the same value generated by the DBTable connector when configured with
{{SHA1}} as "Password cipher algorithm":
{code}
5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
{code}
Besides the letter case (should we worry about this anyway?), do you think that
it is reliable to empower Commons Codec to convert HEX digests to BASE64 and
vice-versa:
{code}
byte[] decodedHex = Hex.decodeHex(hex);
byte[] encodedHexB64 = Base64.codeBase64(decodedHex);
{code}
If this works for our purposes, I don't think there is need to change
{{PasswordEncoder}}'s behavior, e.g. leave everything to HEX and only handle
BASE64->HEX conversion in {{LDAPPasswordSyncActions}} (or any other password
sync actions for resources using BASE64 digest).
WDYT?
> Support synchronizing non-cleartext passwords from external resources
> -
>
> Key: SYNCOPE-313
> URL: https://issues.apache.org/jira/browse/SYNCOPE-313
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Currently we can synchronize cleartext passwords from external resources.
> However, we can't handle non-cleartext passwords, as they get treated as if
> they are plaintext passwords when imported into Syncope, and hence hashed
> again according to user.cipherAlgorithm().
> This task is to treat an imported password as hashed according to a give
> cipher algorithm configured on the connector (for example via 'Password
> Cipher Algorithm' for the DB Connector).
> This is specific to each individual connector, as for example for the DB
> Connector, it might just be a hashed value stored in a table, whereas for
> LDAP it'll be of the form "CIPHER}VALUE" etc.
> Note that we we cannot refer to any specific connector bundle from inside the
> SyncopeSyncResultHandler, hence we should find the cleanest place to
> encapsulate the following logic:
> if (password.isClearText()) {
> // do as currently done
> } else {
> if (connector.isLDAP()) {
>// extract cipher and value
> } else if (connector.isDBTable()) {
>// treat value as ciphered with the cipher defined in connector
> configuration
> } else {
> ...
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026321#comment-14026321
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
The user password that is encoded currently in PasswordEncoder.encode is of the
form "{SHA}XYZ=" for the LDAP use-case. It appears that the password is just
imported "as is". Note that I am not using the "password synchronization"
feature of the LDAP Connector, just ticking the "retrieve passwords" checkbox.
Colm.
> Support synchronizing non-cleartext passwords from external resources
> -
>
> Key: SYNCOPE-313
> URL: https://issues.apache.org/jira/browse/SYNCOPE-313
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Currently we can synchronize cleartext passwords from external resources.
> However, we can't handle non-cleartext passwords, as they get treated as if
> they are plaintext passwords when imported into Syncope, and hence hashed
> again according to user.cipherAlgorithm().
> This task is to treat an imported password as hashed according to a give
> cipher algorithm configured on the connector (for example via 'Password
> Cipher Algorithm' for the DB Connector).
> This is specific to each individual connector, as for example for the DB
> Connector, it might just be a hashed value stored in a table, whereas for
> LDAP it'll be of the form "CIPHER}VALUE" etc.
> Note that we we cannot refer to any specific connector bundle from inside the
> SyncopeSyncResultHandler, hence we should find the cleanest place to
> encapsulate the following logic:
> if (password.isClearText()) {
> // do as currently done
> } else {
> if (connector.isLDAP()) {
>// extract cipher and value
> } else if (connector.isDBTable()) {
>// treat value as ciphered with the cipher defined in connector
> configuration
> } else {
> ...
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026310#comment-14026310
]
Francesco Chicchiriccò commented on SYNCOPE-313:
About the list of actions I've created SYNCOPE-502.
About the password from LDAP, I am not sure that the actual password value
returned by the connector as {{GuardedString}} and decoded as reported in [this
gist|https://gist.github.com/ilgrosso/6389336] does not match the value encoded
by {{PasswordEncoder}} - the Base64 encode / decode should be in charge of
connector logic AFAIR: have you already performed some tests?
> Support synchronizing non-cleartext passwords from external resources
> -
>
> Key: SYNCOPE-313
> URL: https://issues.apache.org/jira/browse/SYNCOPE-313
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Currently we can synchronize cleartext passwords from external resources.
> However, we can't handle non-cleartext passwords, as they get treated as if
> they are plaintext passwords when imported into Syncope, and hence hashed
> again according to user.cipherAlgorithm().
> This task is to treat an imported password as hashed according to a give
> cipher algorithm configured on the connector (for example via 'Password
> Cipher Algorithm' for the DB Connector).
> This is specific to each individual connector, as for example for the DB
> Connector, it might just be a hashed value stored in a table, whereas for
> LDAP it'll be of the form "CIPHER}VALUE" etc.
> Note that we we cannot refer to any specific connector bundle from inside the
> SyncopeSyncResultHandler, hence we should find the cleanest place to
> encapsulate the following logic:
> if (password.isClearText()) {
> // do as currently done
> } else {
> if (connector.isLDAP()) {
>// extract cipher and value
> } else if (connector.isDBTable()) {
>// treat value as ciphered with the cipher defined in connector
> configuration
> } else {
> ...
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (SYNCOPE-502) Allow list of PropagationActions for Resource, SyncActions for SyncTask and PushActions for PushTask
Francesco Chicchiriccò created SYNCOPE-502:
--
Summary: Allow list of PropagationActions for Resource,
SyncActions for SyncTask and PushActions for PushTask
Key: SYNCOPE-502
URL: https://issues.apache.org/jira/browse/SYNCOPE-502
Project: Syncope
Issue Type: Improvement
Reporter: Francesco Chicchiriccò
Fix For: 1.2.0
Currently {{Resource}} can define a single
[PropagationActions|https://cwiki.apache.org/confluence/display/SYNCOPE/PropagationActionsClass]
class, {{SyncTask}} can define a single
[SyncActions|https://cwiki.apache.org/confluence/display/SYNCOPE/SyncActionsClass]
and {{PushTask}} can define a single {{PushActions}} class.
This is somewhat limiting: a list of actions class, to be invoked in the
specified order, looks more powerful.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026295#comment-14026295
]
Colm O hEigeartaigh commented on SYNCOPE-313:
-
Hi Francesco,
Ok thanks for the clarification. I think allowing a list of propagation + sync
actions makes sense, so that we could support the new password + membership
sync actions behaviours at the same time, for example.
To clarify the password encoding issue: Currently, the PasswordEncoder
hard-codes the digest output to HEX:
digester.setStringOutputType(CommonUtils.STRING_OUTPUT_TYPE_HEXADECIMAL);
So let's say our LDAPPasswordSynchronizationAction is taking the encoded
password + setting it directly into SyncopeUser. For the LDAP example, it is
BASE-64 encoded. However, when we try to verify a password next, we end up
comparing a BASE-64 encoded digest stored in SyncopeUser with the HEX encoded
digest generated in PasswordEncoder.verify.
Does that make sense?
Colm.
> Support synchronizing non-cleartext passwords from external resources
> -
>
> Key: SYNCOPE-313
> URL: https://issues.apache.org/jira/browse/SYNCOPE-313
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Currently we can synchronize cleartext passwords from external resources.
> However, we can't handle non-cleartext passwords, as they get treated as if
> they are plaintext passwords when imported into Syncope, and hence hashed
> again according to user.cipherAlgorithm().
> This task is to treat an imported password as hashed according to a give
> cipher algorithm configured on the connector (for example via 'Password
> Cipher Algorithm' for the DB Connector).
> This is specific to each individual connector, as for example for the DB
> Connector, it might just be a hashed value stored in a table, whereas for
> LDAP it'll be of the form "CIPHER}VALUE" etc.
> Note that we we cannot refer to any specific connector bundle from inside the
> SyncopeSyncResultHandler, hence we should find the cleanest place to
> encapsulate the following logic:
> if (password.isClearText()) {
> // do as currently done
> } else {
> if (connector.isLDAP()) {
>// extract cipher and value
> } else if (connector.isDBTable()) {
>// treat value as ciphered with the cipher defined in connector
> configuration
> } else {
> ...
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-313) Support synchronizing non-cleartext passwords from external resources
[
https://issues.apache.org/jira/browse/SYNCOPE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026286#comment-14026286
]
Francesco Chicchiriccò commented on SYNCOPE-313:
{quote}
a) By "synchronization actions" are you referring to the existing Actions class
that you can select in the Resource configuration? (e.g.
LDAPMembershipPropagationAction), or something new that would be associated
with the Connector itself?
{quote}
I mean the [action
class|https://cwiki.apache.org/confluence/display/SYNCOPE/SyncActionsClass]
that can be configured for Sync Tasks - (so {{LDAPMembershipSyncActions}} for
what you refer above).
Since we already provide {{LDAPMembershipSyncActions}} and we are about to
provide {{LDAPPasswordSyncActions}}, it might be also an idea to allow
associating a list of Sync Actions classes to a Sync Task - and correspondingly
a list of Propagation Actions classes to a Resource.
{quote}
We still have the problem with BASE-64/HEX encoding that I raised. What do you
think of my first two points?
{quote}
I am at the moment working on the {{PasswordEncoder}} (locally renamed as
{{Encryptor}} as I am working on SYNCOPE-270) but I have to admin I am not able
to see the problem you report above. Can you please provide more details?
> Support synchronizing non-cleartext passwords from external resources
> -
>
> Key: SYNCOPE-313
> URL: https://issues.apache.org/jira/browse/SYNCOPE-313
> Project: Syncope
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.2.0
>
>
> Currently we can synchronize cleartext passwords from external resources.
> However, we can't handle non-cleartext passwords, as they get treated as if
> they are plaintext passwords when imported into Syncope, and hence hashed
> again according to user.cipherAlgorithm().
> This task is to treat an imported password as hashed according to a give
> cipher algorithm configured on the connector (for example via 'Password
> Cipher Algorithm' for the DB Connector).
> This is specific to each individual connector, as for example for the DB
> Connector, it might just be a hashed value stored in a table, whereas for
> LDAP it'll be of the form "CIPHER}VALUE" etc.
> Note that we we cannot refer to any specific connector bundle from inside the
> SyncopeSyncResultHandler, hence we should find the cleanest place to
> encapsulate the following logic:
> if (password.isClearText()) {
> // do as currently done
> } else {
> if (connector.isLDAP()) {
>// extract cipher and value
> } else if (connector.isDBTable()) {
>// treat value as ciphered with the cipher defined in connector
> configuration
> } else {
> ...
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SYNCOPE-501) Virtual attribute propagation not working when updating only virtual attributes
[ https://issues.apache.org/jira/browse/SYNCOPE-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026282#comment-14026282 ] Andrea Patricelli commented on SYNCOPE-501: --- It would be useful and not negligible to check this situation also for membership virtual attributes. > Virtual attribute propagation not working when updating only virtual > attributes > --- > > Key: SYNCOPE-501 > URL: https://issues.apache.org/jira/browse/SYNCOPE-501 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.8, 1.2.0 >Reporter: Andrea Patricelli >Assignee: Andrea Patricelli > Fix For: 1.1.8, 1.2.0 > > > During User update, if updating ONLY mapped virtual attributes, are they > really propagated? > It seems that core doesn't track these changes and virtual attribute > modifications (in this case) aren't propagated. > If, instead, we update also other normal attribute(s), mapped with resource, > virtual attributes changes are really propagated. > Aren't modification made by solution of issue [1] enough to satisfy this > requirement? > [1] https://issues.apache.org/jira/browse/SYNCOPE-459 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (SYNCOPE-501) Virtual attribute propagation not working when updating only virtual attributes
[ https://issues.apache.org/jira/browse/SYNCOPE-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Patricelli reassigned SYNCOPE-501: - Assignee: Andrea Patricelli > Virtual attribute propagation not working when updating only virtual > attributes > --- > > Key: SYNCOPE-501 > URL: https://issues.apache.org/jira/browse/SYNCOPE-501 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.8, 1.2.0 >Reporter: Andrea Patricelli >Assignee: Andrea Patricelli > Fix For: 1.1.8, 1.2.0 > > > During User update, if updating ONLY mapped virtual attributes, are they > really propagated? > It seems that core doesn't track these changes and virtual attribute > modifications (in this case) aren't propagated. > If, instead, we update also other normal attribute(s), mapped with resource, > virtual attributes changes are really propagated. > Aren't modification made by solution of issue [1] enough to satisfy this > requirement? > [1] https://issues.apache.org/jira/browse/SYNCOPE-459 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (SYNCOPE-458) Change membership virtual attribute management
[ https://issues.apache.org/jira/browse/SYNCOPE-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Patricelli resolved SYNCOPE-458. --- Resolution: Fixed > Change membership virtual attribute management > -- > > Key: SYNCOPE-458 > URL: https://issues.apache.org/jira/browse/SYNCOPE-458 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.5 >Reporter: fabio martelli >Assignee: Andrea Patricelli > Fix For: 1.2.0 > > > Consider that memberships are not directly interested by a propagation. > Membership virtual attribute have to be considered like user virtual > attribute: > 1. retrieve membership virtual attribute values as done for user attributes > 2. manage membership virtual attributes during propagation (create/update) > 3. manage membership virtual attributes during membership remove -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SYNCOPE-458) Change membership virtual attribute management
[ https://issues.apache.org/jira/browse/SYNCOPE-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026279#comment-14026279 ] ASF subversion and git services commented on SYNCOPE-458: - Commit 1601588 from [~andrea.patricelli] in branch 'syncope/trunk' [ https://svn.apache.org/r1601588 ] [SYNCOPE-458] improved membership virtual attribute management > Change membership virtual attribute management > -- > > Key: SYNCOPE-458 > URL: https://issues.apache.org/jira/browse/SYNCOPE-458 > Project: Syncope > Issue Type: Bug > Components: core >Affects Versions: 1.1.5 >Reporter: fabio martelli >Assignee: Andrea Patricelli > Fix For: 1.2.0 > > > Consider that memberships are not directly interested by a propagation. > Membership virtual attribute have to be considered like user virtual > attribute: > 1. retrieve membership virtual attribute values as done for user attributes > 2. manage membership virtual attributes during propagation (create/update) > 3. manage membership virtual attributes during membership remove -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (SYNCOPE-501) Virtual attribute propagation not working when updating only virtual attributes
Andrea Patricelli created SYNCOPE-501: - Summary: Virtual attribute propagation not working when updating only virtual attributes Key: SYNCOPE-501 URL: https://issues.apache.org/jira/browse/SYNCOPE-501 Project: Syncope Issue Type: Bug Components: core Affects Versions: 1.1.8, 1.2.0 Reporter: Andrea Patricelli Fix For: 1.1.8, 1.2.0 During User update, if updating ONLY mapped virtual attributes, are they really propagated? It seems that core doesn't track these changes and virtual attribute modifications (in this case) aren't propagated. If, instead, we update also other normal attribute(s), mapped with resource, virtual attributes changes are really propagated. Aren't modification made by solution of issue [1] enough to satisfy this requirement? [1] https://issues.apache.org/jira/browse/SYNCOPE-459 -- This message was sent by Atlassian JIRA (v6.2#6252)
