Uploaded image for project: 'Syncope'
  1. Syncope
  2. SYNCOPE-313

Support synchronizing non-cleartext passwords from external resources

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.0-M1
    • Component/s: None
    • Labels:
      None

      Description

      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

      { ... }

      }

        Issue Links

          Activity

          Hide
          jflemer James Flemer added a comment -

          I've implemented something like this in a private branch of Syncope. It's probably not flexible enough to commit into the main branch, but works well in the (limited) ecosystem I use. I can provide patches...

          Show
          jflemer James Flemer added a comment - I've implemented something like this in a private branch of Syncope. It's probably not flexible enough to commit into the main branch, but works well in the (limited) ecosystem I use. I can provide patches...
          Hide
          ilgrosso Francesco Chicchiriccò added a comment -

          I am not sure if Colm O hEigeartaigh is actively working on this issue, anyway I'd say any patch is more than welcome, even as a starting point

          If you decide to provide a patch, please send an ICLA before, thanks!

          Show
          ilgrosso Francesco Chicchiriccò added a comment - I am not sure if Colm O hEigeartaigh is actively working on this issue, anyway I'd say any patch is more than welcome, even as a starting point If you decide to provide a patch, please send an ICLA before, thanks!
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          Yup please attach patches to this JIRA + I will review!

          Thanks,

          Colm.

          Show
          coheigea Colm O hEigeartaigh added a comment - Yup please attach patches to this JIRA + I will review! Thanks, Colm.
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          Hi James,

          Any update on some potential patches for this issue?

          Colm.

          Show
          coheigea Colm O hEigeartaigh added a comment - Hi James, Any update on some potential patches for this issue? Colm.
          Hide
          ilgrosso Francesco Chicchiriccò added a comment -

          Relevant discussion in user ML.

          Show
          ilgrosso Francesco Chicchiriccò added a comment - Relevant discussion in user ML.
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          Hi all,

          I'm just starting to look into this topic again. Here is an initial proposal, feedback welcome!

          • A current limitation of Syncope is that password encoding (when digesting) is hardcoded to HEX in PasswordEncoder. I propose that this should be configurable (password.cipher.encoding or something) so that we can also support BASE-64 encoding.
          • A new Connector property for the relevant connectors is added to specify whether the password is encoded in either HEX or BASE-64.
          • Let's assume we are dealing with LDAP where we might have passwords encoded in the form " {sha}

            XYZ=", or they could be in plaintext. On synchronization, if it doesn't start with "

            {hash-alg}" then we treat it as plaintext, and hash according to the default value + encode according to the default value. If it does start with "{hash-alg}

            ", the cipherAlgorithm parameter of a SyncopeUser will get populated by the hash algorithm specified in the password first, and fall back to the default value if it doesn't exist. SyncopeUser will also have a password encoding value derived from the Connector, which will also fall back to the default value. In this case (hashed password), we do not explicitly encode the password via PasswordEncoder, but just use the value we receive (minus the "

            {hash-alg}

            " prefix).

          • For a SQL table, we will have to add a new hash algorithm parameter, so that we know that the values received are hashed + that we can treat them as such.

          Does this broadly make sense or is there a better way? If the former, then I will start looking into how this will actually work without polluting the SyncopeSyncResultHandler will Connector-specific stuff.

          Colm.

          Show
          coheigea Colm O hEigeartaigh added a comment - Hi all, I'm just starting to look into this topic again. Here is an initial proposal, feedback welcome! A current limitation of Syncope is that password encoding (when digesting) is hardcoded to HEX in PasswordEncoder. I propose that this should be configurable (password.cipher.encoding or something) so that we can also support BASE-64 encoding. A new Connector property for the relevant connectors is added to specify whether the password is encoded in either HEX or BASE-64. Let's assume we are dealing with LDAP where we might have passwords encoded in the form " {sha} XYZ=", or they could be in plaintext. On synchronization, if it doesn't start with " {hash-alg}" then we treat it as plaintext, and hash according to the default value + encode according to the default value. If it does start with "{hash-alg} ", the cipherAlgorithm parameter of a SyncopeUser will get populated by the hash algorithm specified in the password first, and fall back to the default value if it doesn't exist. SyncopeUser will also have a password encoding value derived from the Connector, which will also fall back to the default value. In this case (hashed password), we do not explicitly encode the password via PasswordEncoder, but just use the value we receive (minus the " {hash-alg} " prefix). For a SQL table, we will have to add a new hash algorithm parameter, so that we know that the values received are hashed + that we can treat them as such. Does this broadly make sense or is there a better way? If the former, then I will start looking into how this will actually work without polluting the SyncopeSyncResultHandler will Connector-specific stuff. Colm.
          Hide
          ilgrosso Francesco Chicchiriccò added a comment - - edited

          I was more thinking that a possible way to implement this feature was to provide specific synchronization actions for relevant connectors (say LDAP and DBTable) so that the technology-specific handling could have been coded in there.

          The LDAPPasswordSynchronizationAction could parse the password value from connector (say "{SSHA}jkdsfjlksdjfklsdjfkjsdflsdjkfdslfsdkjfk"), check that SSHA is supported by Syncope and then directly set the encoded value into SyncopeUser (this is currently not possible).

          The DBPasswordSynchronizationAction could look at the connector configuration (the "Password cipher algorithm" parameter - see https://connid.atlassian.net/wiki/display/BASE/Database+Table) and then directly set the encoded value into SyncopeUser (this is currently not possible).

          WDYT?

          Show
          ilgrosso Francesco Chicchiriccò added a comment - - edited I was more thinking that a possible way to implement this feature was to provide specific synchronization actions for relevant connectors (say LDAP and DBTable) so that the technology-specific handling could have been coded in there. The LDAPPasswordSynchronizationAction could parse the password value from connector (say "{SSHA}jkdsfjlksdjfklsdjfkjsdflsdjkfdslfsdkjfk"), check that SSHA is supported by Syncope and then directly set the encoded value into SyncopeUser (this is currently not possible). The DBPasswordSynchronizationAction could look at the connector configuration (the "Password cipher algorithm" parameter - see https://connid.atlassian.net/wiki/display/BASE/Database+Table ) and then directly set the encoded value into SyncopeUser (this is currently not possible). WDYT?
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          Hi Francesco,

          That sounds reasonable to me. Two questions though:

          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?

          b) We still have the problem with BASE-64/HEX encoding that I raised. What do you think of my first two points?

          Thanks,

          Colm.

          Show
          coheigea Colm O hEigeartaigh added a comment - Hi Francesco, That sounds reasonable to me. Two questions though: 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? b) We still have the problem with BASE-64/HEX encoding that I raised. What do you think of my first two points? Thanks, Colm.
          Hide
          ilgrosso Francesco Chicchiriccò added a comment -

          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?

          I mean the action class 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.

          We still have the problem with BASE-64/HEX encoding that I raised. What do you think of my first two points?

          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?

          Show
          ilgrosso Francesco Chicchiriccò added a comment - 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? I mean the action class 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. We still have the problem with BASE-64/HEX encoding that I raised. What do you think of my first two points? 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?
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          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.

          Show
          coheigea Colm O hEigeartaigh added a comment - 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.
          Hide
          ilgrosso Francesco Chicchiriccò added a comment -

          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 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?

          Show
          ilgrosso Francesco Chicchiriccò added a comment - 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 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?
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          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.

          Show
          coheigea Colm O hEigeartaigh added a comment - 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.
          Hide
          ilgrosso Francesco Chicchiriccò added a comment -

          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

          {SSHA}nuCQ3hYajf2HUcfdIUj48C5eqA7x94ks
          

          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

          5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
          

          which is the same value - apart from letter case - returned, for example, by internal MySQL function:

          mysql> select sha1('password');
          +------------------------------------------+
          | sha1('password')                         |
          +------------------------------------------+
          | 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 |
          +------------------------------------------+
          

          and also the same value generated by the DBTable connector when configured with SHA1 as "Password cipher algorithm":

          5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
          

          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:

          byte[] decodedHex = Hex.decodeHex(hex);
          byte[] encodedHexB64 = Base64.codeBase64(decodedHex);
          

          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?

          Show
          ilgrosso Francesco Chicchiriccò added a comment - 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 {SSHA}nuCQ3hYajf2HUcfdIUj48C5eqA7x94ks 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 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8 which is the same value - apart from letter case - returned, for example, by internal MySQL function: mysql> select sha1('password'); +------------------------------------------+ | sha1('password') | +------------------------------------------+ | 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 | +------------------------------------------+ and also the same value generated by the DBTable connector when configured with SHA1 as "Password cipher algorithm": 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 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: byte [] decodedHex = Hex.decodeHex(hex); byte [] encodedHexB64 = Base64.codeBase64(decodedHex); 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?
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          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.

          Show
          coheigea Colm O hEigeartaigh added a comment - 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.
          Hide
          ilgrosso Francesco Chicchiriccò added a comment -

          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.

          Show
          ilgrosso Francesco Chicchiriccò added a comment - 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.
          Hide
          coheigea Colm O hEigeartaigh added a comment - - edited

          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.

          Show
          coheigea Colm O hEigeartaigh added a comment - - edited 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.
          Hide
          ilgrosso Francesco Chicchiriccò added a comment -

          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).

          Show
          ilgrosso Francesco Chicchiriccò added a comment - 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 ).
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          Sounds good!

          Colm.

          Show
          coheigea Colm O hEigeartaigh added a comment - Sounds good! Colm.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1601940 from Colm O hEigeartaigh in branch 'syncope/trunk'
          [ https://svn.apache.org/r1601940 ]

          SYNCOPE-313 - Adding an initial way to import hashed passwords into Syncope from an LDAP backend

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1601940 from Colm O hEigeartaigh in branch 'syncope/trunk' [ https://svn.apache.org/r1601940 ] SYNCOPE-313 - Adding an initial way to import hashed passwords into Syncope from an LDAP backend
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          Initial implementation of LDAPPasswordSyncActions committed. I've tested it with plaintext, SHA-1 + SHA-256 encoded passwords in Apache DS and it works. The salted settings in PasswordEncoder appear to differ from what Apache DS does, but this is not a priority for the moment. An initial (stupid) question: I am just updating SyncopeUser in LDAPPasswordSyncActions. Is it necessary to also create a UserMod with the changed password + call UserWorkflowAdapter.update on it?

          Colm.

          Show
          coheigea Colm O hEigeartaigh added a comment - Initial implementation of LDAPPasswordSyncActions committed. I've tested it with plaintext, SHA-1 + SHA-256 encoded passwords in Apache DS and it works. The salted settings in PasswordEncoder appear to differ from what Apache DS does, but this is not a priority for the moment. An initial (stupid) question: I am just updating SyncopeUser in LDAPPasswordSyncActions. Is it necessary to also create a UserMod with the changed password + call UserWorkflowAdapter.update on it? Colm.
          Hide
          ilgrosso Francesco Chicchiriccò added a comment -

          Looks good!
          The actions class is called as part of the user workflow, so updating SyncopeUser is exactly what needs to be done.

          Two minor questions:

          1. any particular reason why not to replace SHA1("SHA-1", false) with SHA("SHA-1", false)?
          2. the last argument in SyncopeUser#setEncodedPassword looks not-needed: correct?
          Show
          ilgrosso Francesco Chicchiriccò added a comment - Looks good! The actions class is called as part of the user workflow, so updating SyncopeUser is exactly what needs to be done. Two minor questions: any particular reason why not to replace SHA1("SHA-1", false) with SHA("SHA-1", false)? the last argument in SyncopeUser#setEncodedPassword looks not-needed: correct?
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          Hi Francesco,

          > any particular reason why not to replace SHA1("SHA-1", false) with SHA("SHA-1", false)?

          I just left SHA1 there for backwards compatibility reasons, so that a value of "SHA1" as part of the password cipher algorithm would still work. I don't see any harm in having both SHA + SHA1 map to the same thing.

          > the last argument in SyncopeUser#setEncodedPassword looks not-needed: correct?

          Yep.

          What do you think about backporting the SyncopeUser + CipherAlgorithm changes (just the SHA addition) to 1.1.x? At least then a user could plug in their own SyncActions implementation to support this behaviour if required.

          Colm.

          Show
          coheigea Colm O hEigeartaigh added a comment - Hi Francesco, > any particular reason why not to replace SHA1("SHA-1", false) with SHA("SHA-1", false)? I just left SHA1 there for backwards compatibility reasons, so that a value of "SHA1" as part of the password cipher algorithm would still work. I don't see any harm in having both SHA + SHA1 map to the same thing. > the last argument in SyncopeUser#setEncodedPassword looks not-needed: correct? Yep. What do you think about backporting the SyncopeUser + CipherAlgorithm changes (just the SHA addition) to 1.1.x? At least then a user could plug in their own SyncActions implementation to support this behaviour if required. Colm.
          Hide
          ilgrosso Francesco Chicchiriccò added a comment -

          What do you think about backporting the SyncopeUser + CipherAlgorithm changes (just the SHA addition) to 1.1.x? At least then a user could plug in their own SyncActions implementation to support this behaviour if required.

          +1

          Show
          ilgrosso Francesco Chicchiriccò added a comment - What do you think about backporting the SyncopeUser + CipherAlgorithm changes (just the SHA addition) to 1.1.x? At least then a user could plug in their own SyncActions implementation to support this behaviour if required. +1
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1602193 from Colm O hEigeartaigh in branch 'syncope/branches/1_1_X'
          [ https://svn.apache.org/r1602193 ]

          SYNCOPE-313 - Adding an initial way to import hashed passwords into Syncope from an LDAP backend

          Conflicts:
          common/src/main/java/org/apache/syncope/common/types/CipherAlgorithm.java

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1602193 from Colm O hEigeartaigh in branch 'syncope/branches/1_1_X' [ https://svn.apache.org/r1602193 ] SYNCOPE-313 - Adding an initial way to import hashed passwords into Syncope from an LDAP backend Conflicts: common/src/main/java/org/apache/syncope/common/types/CipherAlgorithm.java
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1602209 from Colm O hEigeartaigh in branch 'syncope/trunk'
          [ https://svn.apache.org/r1602209 ]

          SYNCOPE-313 - SyncActions implementation to sync passwords from a Database

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1602209 from Colm O hEigeartaigh in branch 'syncope/trunk' [ https://svn.apache.org/r1602209 ] SYNCOPE-313 - SyncActions implementation to sync passwords from a Database
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          Tested both LDAP + DB SyncActions properly.

          Colm.

          Show
          coheigea Colm O hEigeartaigh added a comment - Tested both LDAP + DB SyncActions properly. Colm.
          Hide
          ilgrosso Francesco Chicchiriccò added a comment -

          Any plan for adding an integration test case for this feature?

          Show
          ilgrosso Francesco Chicchiriccò added a comment - Any plan for adding an integration test case for this feature?
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          Integration tests merged for SYNCOPE-505. Is there any example of a SyncTask executing successfully in the integration test-code? The idea I had was to extend the tests in SYNCOPE-505, by changing the local password, and then sync'ing from the resource again + checking the password was changed. When I add a SyncTask via something like this, it doesn't seem to have fired (in time?) and the user is not updated:

          SyncTaskTO syncTask = new SyncTaskTO();
          syncTask.setName("DB Sync Task");
          syncTask.setDescription("DB Sync Task description");
          syncTask.setPerformCreate(true);
          syncTask.setPerformUpdate(true);
          syncTask.setFullReconciliation(true);
          syncTask.setResource(RESOURCE_NAME_TESTDB);
          syncTask.setStartDate(new Date());
          syncTask.getActionsClassNames().add(DBPasswordSyncActions.class.getName());
          Response taskResponse = taskService.create(syncTask);
          String taskId = taskResponse.getHeaderString(RESTHeaders.RESOURCE_ID);
          TaskExecTO taskExec = taskService.execute(Long.valueOf(taskId), false);

          Any ideas?

          Colm.

          Show
          coheigea Colm O hEigeartaigh added a comment - Integration tests merged for SYNCOPE-505 . Is there any example of a SyncTask executing successfully in the integration test-code? The idea I had was to extend the tests in SYNCOPE-505 , by changing the local password, and then sync'ing from the resource again + checking the password was changed. When I add a SyncTask via something like this, it doesn't seem to have fired (in time?) and the user is not updated: SyncTaskTO syncTask = new SyncTaskTO(); syncTask.setName("DB Sync Task"); syncTask.setDescription("DB Sync Task description"); syncTask.setPerformCreate(true); syncTask.setPerformUpdate(true); syncTask.setFullReconciliation(true); syncTask.setResource(RESOURCE_NAME_TESTDB); syncTask.setStartDate(new Date()); syncTask.getActionsClassNames().add(DBPasswordSyncActions.class.getName()); Response taskResponse = taskService.create(syncTask); String taskId = taskResponse.getHeaderString(RESTHeaders.RESOURCE_ID); TaskExecTO taskExec = taskService.execute(Long.valueOf(taskId), false); Any ideas? Colm.
          Hide
          ilgrosso Francesco Chicchiriccò added a comment - - edited

          Take a look at TaskTestITCase - there is plenty of SyncTask executions.

          Show
          ilgrosso Francesco Chicchiriccò added a comment - - edited Take a look at TaskTestITCase - there is plenty of SyncTask executions.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1607419 from Colm O hEigeartaigh in branch 'syncope/trunk'
          [ https://svn.apache.org/r1607419 ]

          SYNCOPE-313 - Added integration tests

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1607419 from Colm O hEigeartaigh in branch 'syncope/trunk' [ https://svn.apache.org/r1607419 ] SYNCOPE-313 - Added integration tests
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          Tests committed. I @Ignore'd the LDAP test, as it seems to be causing a side-effect on reconcileFromLDAP for some reason.

          Colm.

          Show
          coheigea Colm O hEigeartaigh added a comment - Tests committed. I @Ignore'd the LDAP test, as it seems to be causing a side-effect on reconcileFromLDAP for some reason. Colm.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1607611 from Francesco Chicchiriccò in branch 'syncope/trunk'
          [ https://svn.apache.org/r1607611 ]

          SYNCOPE-313 Resolving IT conflicts

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1607611 from Francesco Chicchiriccò in branch 'syncope/trunk' [ https://svn.apache.org/r1607611 ] SYNCOPE-313 Resolving IT conflicts
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1607871 from Francesco Chicchiriccò in branch 'syncope/trunk'
          [ https://svn.apache.org/r1607871 ]

          SYNCOPE-313 Resolving IT conflicts (XML)

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1607871 from Francesco Chicchiriccò in branch 'syncope/trunk' [ https://svn.apache.org/r1607871 ] SYNCOPE-313 Resolving IT conflicts (XML)
          Hide
          ilgrosso Francesco Chicchiriccò added a comment -

          Bulk close for 1.2.0-M1

          Show
          ilgrosso Francesco Chicchiriccò added a comment - Bulk close for 1.2.0-M1

            People

            • Assignee:
              coheigea Colm O hEigeartaigh
              Reporter:
              coheigea Colm O hEigeartaigh
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development