Re: PWM as password manager
On 06/11/2014 18:32, Martin van Es wrote:
HI Francesco,
On Thu, Nov 6, 2014 at 5:36 PM, Francesco Chicchiriccò
wrote:
Ok, then you need a synchronization action class that, when synchronizing
from LDAP will inspect the password value and remove it from synchronization
attributes if the password values starts with {SSHA}.
I was hoping I could solve this without programming ;)
Maybe one day I will pick up this challenge...
Well, not a big deal, actually: you can take [1] as reference and
simplify its logic to remove password values starting with "{SSHA}".
Regards.
[1]
https://git-wip-us.apache.org/repos/asf?p=syncope.git;a=blob;f=core/src/main/java/org/apache/syncope/core/sync/impl/LDAPPasswordSyncActions.java;h=65f43cc70959166b97794a4f481dbef73008977a;hb=1_2_X
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: PWM as password manager
HI Francesco,
On Thu, Nov 6, 2014 at 5:36 PM, Francesco Chicchiriccò
wrote:
>
> Ok, then you need a synchronization action class that, when synchronizing
> from LDAP will inspect the password value and remove it from synchronization
> attributes if the password values starts with {SSHA}.
I was hoping I could solve this without programming ;)
Maybe one day I will pick up this challenge...
Regards,
Martin
Re: PWM as password manager
On 06/11/2014 17:17, Martin van Es wrote:
Hi Francesco,
On Thu, Nov 6, 2014 at 4:34 PM, Francesco Chicchiriccò
wrote:
On 05/11/2014 19:09, Martin van Es wrote:
Hope this clarifies my endavours a bit.
Only a bit, actually :-)
But still I don't get why you are not just using AES on Syncope: any
propagation will then be able to re-obtain clear-text password.
Isn't this that you just need?
Yes, AES is key to my quest, but I want PWM to be the point where
people set and reset their password, not Syncope. PWM can only talk to
LDAP so I need to temporary write password plaintext to LDAP so
Syncope can pick it up. I don't want any plaintext password left in
LDAP after succesful synchronisation from LDAP to Syncope and back.
This can be accomplished by propagating the now AES encrypted password
in Syncope back to LDAP as SSHA hash (so far, so good).
But now, if I resync LDAP, the SSHA hash gets synced to Syncope,
because there is no plaintext password anymore and at this point I
loose the AES decryptable password in Syncopy. There is no way I can
tell Syncope to only accept plaintext passwords from LDAP and not the
SSHA hashed ones.
Ok, then you need a synchronization action class that, when
synchronizing from LDAP will inspect the password value and remove it
from synchronization attributes if the password values starts with {SSHA}.
HTH
Regards.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: PWM as password manager
Hi Francesco, On Thu, Nov 6, 2014 at 4:34 PM, Francesco Chicchiriccò wrote: > On 05/11/2014 19:09, Martin van Es wrote: >> Hope this clarifies my endavours a bit. > > > Only a bit, actually :-) > > But still I don't get why you are not just using AES on Syncope: any > propagation will then be able to re-obtain clear-text password. > Isn't this that you just need? Yes, AES is key to my quest, but I want PWM to be the point where people set and reset their password, not Syncope. PWM can only talk to LDAP so I need to temporary write password plaintext to LDAP so Syncope can pick it up. I don't want any plaintext password left in LDAP after succesful synchronisation from LDAP to Syncope and back. This can be accomplished by propagating the now AES encrypted password in Syncope back to LDAP as SSHA hash (so far, so good). But now, if I resync LDAP, the SSHA hash gets synced to Syncope, because there is no plaintext password anymore and at this point I loose the AES decryptable password in Syncopy. There is no way I can tell Syncope to only accept plaintext passwords from LDAP and not the SSHA hashed ones. Regards, Martin
Re: PWM as password manager
On 05/11/2014 19:09, Martin van Es wrote: Hi Fransesco, I agree the setup makes no sense, it is all for the sake of testing. It's a lab! What I wish to accomplish is to make PWM (via LDAP) leading in password (re)set, but have the ability to propagate the password at ANY given time from Syncope in ANY form I would like or need (depending on resource). I also want to have no (or at most a very short time) plaintext passwords in the system. To accomplish this, Syncope needs the password symmetrically encrypted at all time. To check that Syncope has knowledge about the symmtrically encrypted password I let the password sync to CSV (because I had no knowledge about the password internals until now). Seeing a SSHA hash in CSV tells me, that Syncope lost that ability to sync the password to any resource (in a form other than SSHA hashed) at a certain point in the process (after the 2nd sync from LDAP precisely). A custom propagation action to csv would not make a difference, because I have allready lost the knowledge of the symmetrically encrypted password in Syncope, as far as I understand the results of my test. Hope this clarifies my endavours a bit. Only a bit, actually :-) But still I don't get why you are not just using AES on Syncope: any propagation will then be able to re-obtain clear-text password. Isn't this that you just need? Regards. On Tue, Nov 4, 2014 at 7:45 AM, Francesco Chicchiriccò wrote: On 02/11/2014 21:31, Martin van Es wrote: Hi Fransesco, On closer investigation it's not as good as I hoped. It's close, but not close enough. I have two test resources. One LDAP and one CSVdir (only push). When I set password in PWM, it writes a plaintext pwd to userPassword field as configured by slapd's plaintext hashing method. If I sync the LDAP resource, the syncope user can authenticate using the new password set in PWM, so I assume the password sync went ok. As a check, I see the password appearing plaintext in the CSV output file, as per my configuration and my requirement. I hope the plaintext password got AES encrypted in syncope, but I can't check that? Just go to internal storage's SyncopeUser table and look for 'password' and 'cipherAlgorithm' columns: the former is the actual stored password, the latter is the algorithm used to cipher it. Now, when I push this password to LDAP again, it gets hashed to it's SSHA equivalent as per my LDAP connector configuration: LDAP authentication still works and I have a hashed password in LDAP as I ultimately want, CSV resource still contains the readable password. Then I sync the LDAP SSHA password back to syncope and syncope authentication still works, but now the CSV resource contains the hashed password, where I hoped syncope would have kept the original AES encrypted version of my first setting in PWM. Syncing this password to LDAP back again make LDAP auth still work, so syncope does not rehash the hash as I would have expected based on the hash in CSV resource?! To fix this, syncope or the ldap connector should become a bit more 'intelligent' about when to sync the password (only if it's plaintext or other equivalent of AES, never sync hashed?) just like it is when pushing the hashed password to LDAP. First of all let me say that I find this situation a bit weird: I cannot see any good reason for having clear passwords anywhere, and especially in a CSV file! I think that the simpler thing you can do is to provide the CSV resource with your own custom propagation action [1] where you can mangle the propagation attributes *before* they actually get to the underlying connector and then to the actual resource. HTH Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/PropagationActionsClass On Tue, Oct 28, 2014 at 12:30 PM, Martin van Es wrote: Hi Francesco, I managed to set pwd in PWM (cleartext in LDAP), sync (full reconcile) to Syncope and (re)propagate the same password SSHA hashed back to LDAP. This scenario more or less fulfills my desired test scenario, apart from the short time the password lives unencrypted in LDAP, but which is hard to overcome without changing PWM (or slapd). I'll try to write-up something for the how-to page. Thx for the patient answers and advice! Regards, Martin On Tue, Oct 28, 2014 at 8:41 AM, Francesco Chicchiriccò wrote: Hi Martin, here's some reply to your questions below. This hypothetical excercise would require a 2-way encrypted password setup between OpenLDAP and Syncope. Is this a possible scenario? Would PLAINTEXT Passwords in LDAP be the only solution? With Syncope 1.2.0 you can synchronize encrypted passwords from LDAP or DB resource and propagate (using the same cipher algorithm, of course) again to other LDAP / DB resources. For this to happen, usage of LDAPPasswordSyncActions / DBPasswordSyncActions (for synchronization) and LDAPPasswordPropagationActions / DBPasswordPropagationActions is required. Another option could be usage of passthrough authentication,
Re: PWM as password manager
Hi Fransesco, I agree the setup makes no sense, it is all for the sake of testing. It's a lab! What I wish to accomplish is to make PWM (via LDAP) leading in password (re)set, but have the ability to propagate the password at ANY given time from Syncope in ANY form I would like or need (depending on resource). I also want to have no (or at most a very short time) plaintext passwords in the system. To accomplish this, Syncope needs the password symmetrically encrypted at all time. To check that Syncope has knowledge about the symmtrically encrypted password I let the password sync to CSV (because I had no knowledge about the password internals until now). Seeing a SSHA hash in CSV tells me, that Syncope lost that ability to sync the password to any resource (in a form other than SSHA hashed) at a certain point in the process (after the 2nd sync from LDAP precisely). A custom propagation action to csv would not make a difference, because I have allready lost the knowledge of the symmetrically encrypted password in Syncope, as far as I understand the results of my test. Hope this clarifies my endavours a bit. Best regards, Martin On Tue, Nov 4, 2014 at 7:45 AM, Francesco Chicchiriccò wrote: > On 02/11/2014 21:31, Martin van Es wrote: > > Hi Fransesco, > > On closer investigation it's not as good as I hoped. It's close, but not > close enough. > > I have two test resources. One LDAP and one CSVdir (only push). When I set > password in PWM, it writes a plaintext pwd to userPassword field as > configured by slapd's plaintext hashing method. If I sync the LDAP resource, > the syncope user can authenticate using the new password set in PWM, so I > assume the password sync went ok. As a check, I see the > password appearing plaintext in the CSV output file, as per my configuration > and my requirement. I hope the plaintext password got AES encrypted in > syncope, but I can't check that? > > > Just go to internal storage's SyncopeUser table and look for 'password' and > 'cipherAlgorithm' columns: the former is the actual stored password, the > latter is the algorithm used to cipher it. > > Now, when I push this password to LDAP again, it gets hashed to it's SSHA > equivalent as per my LDAP connector configuration: LDAP authentication still > works and I have a hashed password in LDAP as I ultimately want, CSV > resource still contains the readable password. > Then I sync the LDAP SSHA password back to syncope and syncope > authentication still works, but now the CSV resource contains the hashed > password, where I hoped syncope would have kept the original AES encrypted > version of my first setting in PWM. Syncing this password to LDAP back again > make LDAP auth still work, so syncope does not rehash the hash as I would > have expected based on the hash in CSV resource?! > > To fix this, syncope or the ldap connector should become a bit more > 'intelligent' about when to sync the password (only if it's plaintext or > other equivalent of AES, never sync hashed?) just like it is when pushing > the hashed password to LDAP. > > > First of all let me say that I find this situation a bit weird: I cannot see > any good reason for having clear passwords anywhere, and especially in a CSV > file! > > I think that the simpler thing you can do is to provide the CSV resource > with your own custom propagation action [1] where you can mangle the > propagation attributes *before* they actually get to the underlying > connector and then to the actual resource. > > HTH > Regards. > > [1] > https://cwiki.apache.org/confluence/display/SYNCOPE/PropagationActionsClass > > > On Tue, Oct 28, 2014 at 12:30 PM, Martin van Es wrote: > > Hi Francesco, > > I managed to set pwd in PWM (cleartext in LDAP), sync (full reconcile) to > Syncope and (re)propagate the same password SSHA hashed back to LDAP. > This scenario more or less fulfills my desired test scenario, apart from the > short time the password lives unencrypted in LDAP, but which is hard to > overcome without changing PWM (or slapd). > > I'll try to write-up something for the how-to page. > > Thx for the patient answers and advice! > > Regards, > Martin > > On Tue, Oct 28, 2014 at 8:41 AM, Francesco Chicchiriccò > wrote: > > Hi Martin, > here's some reply to your questions below. > > This hypothetical excercise would require a 2-way encrypted password setup > between OpenLDAP and Syncope. Is this a possible scenario? Would PLAINTEXT > Passwords in LDAP be the only solution? > > With Syncope 1.2.0 you can synchronize encrypted passwords from LDAP or DB > resource and propagate (using the same cipher algorithm, of course) again to > other LDAP / DB resources. > For this to happen, usage of LDAPPasswordSyncActions / DBPasswordSyncActions > (for synchronization) and LDAPPasswordPropagationActions / > DBPasswordPropagationActions is required. > > Another option could be usage of passthrough authentication, again available > with Syncope 1.2.0: you have the chance to define, in a
Re: PWM as password manager
On 02/11/2014 21:31, Martin van Es wrote: Hi Fransesco, On closer investigation it's not as good as I hoped. It's close, but not close enough. I have two test resources. One LDAP and one CSVdir (only push). When I set password in PWM, it writes a plaintext pwd to userPassword field as configured by slapd's plaintext hashing method. If I sync the LDAP resource, the syncope user can authenticate using the new password set in PWM, so I assume the password sync went ok. As a check, I see the password appearing plaintext in the CSV output file, as per my configuration and my requirement. I hope the plaintext password got AES encrypted in syncope, but I can't check that? Just go to internal storage's SyncopeUser table and look for 'password' and 'cipherAlgorithm' columns: the former is the actual stored password, the latter is the algorithm used to cipher it. Now, when I push this password to LDAP again, it gets hashed to it's SSHA equivalent as per my LDAP connector configuration: LDAP authentication still works and I have a hashed password in LDAP as I ultimately want, CSV resource still contains the readable password. Then I sync the LDAP SSHA password back to syncope and syncope authentication still works, but now the CSV resource contains the hashed password, where I hoped syncope would have kept the original AES encrypted version of my first setting in PWM. Syncing this password to LDAP back again make LDAP auth still work, so syncope does not rehash the hash as I would have expected based on the hash in CSV resource?! To fix this, syncope or the ldap connector should become a bit more 'intelligent' about when to sync the password (only if it's plaintext or other equivalent of AES, never sync hashed?) just like it is when pushing the hashed password to LDAP. First of all let me say that I find this situation a bit weird: I cannot see any good reason for having clear passwords anywhere, and especially in a CSV file! I think that the simpler thing you can do is to provide the CSV resource with your own custom propagation action [1] where you can mangle the propagation attributes *before* they actually get to the underlying connector and then to the actual resource. HTH Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/PropagationActionsClass On Tue, Oct 28, 2014 at 12:30 PM, Martin van Es wrote: Hi Francesco, I managed to set pwd in PWM (cleartext in LDAP), sync (full reconcile) to Syncope and (re)propagate the same password SSHA hashed back to LDAP. This scenario more or less fulfills my desired test scenario, apart from the short time the password lives unencrypted in LDAP, but which is hard to overcome without changing PWM (or slapd). I'll try to write-up something for the how-to page. Thx for the patient answers and advice! Regards, Martin On Tue, Oct 28, 2014 at 8:41 AM, Francesco Chicchiriccò wrote: Hi Martin, here's some reply to your questions below. This hypothetical excercise would require a 2-way encrypted password setup between OpenLDAP and Syncope. Is this a possible scenario? Would PLAINTEXT Passwords in LDAP be the only solution? With Syncope 1.2.0 you can synchronize encrypted passwords from LDAP or DB resource and propagate (using the same cipher algorithm, of course) again to other LDAP / DB resources. For this to happen, usage of LDAPPasswordSyncActions / DBPasswordSyncActions (for synchronization) and LDAPPasswordPropagationActions / DBPasswordPropagationActions is required. Another option could be usage of passthrough authentication, again available with Syncope 1.2.0: you have the chance to define, in a relevant Account Policy, whether authentication (to Syncope core and console) is to be checked against one or more of external resources available. I just learned that the connid LDAP connector does not support sync, unless you're using Sun Directory Server Enterprise Edition? Is this true? Is there no sync possible from LDAP? In Syncope two types of synchronizations are supported (more info [1]), full (calling SEARCH on connectors to get all existing accounts / groups) and incremental (calling SYNC on connectors to get all modified accounts / groups since previous synchronization). The former is not as accurate as latter (for example, it cannot identify any delete on external resource) and also not as efficient (at every execution the whole content is requested by Syncope). The ConnId LDAP connector supports actual SYNC operation from former Sun DSEE (now Oracle DSEE), OpenDS / OpenDJ and Fedora 389 - and at least the latter is actually Open Source ;-) About OpenLDAP, there is a long-standing open issue [2] at ConnId about supporting SYNC - should you be interested in contributing, please join the discussion at connid-...@googelgroups.com. Of course, I'm looking at NetIQ/eDir/SSPR as a commercial example IdM system for my question. It would be nice if Syncope+OpenLDAP+PWM could do this trick as well
Re: PWM as password manager
Hi Fransesco, On closer investigation it's not as good as I hoped. It's close, but not close enough. I have two test resources. One LDAP and one CSVdir (only push). When I set password in PWM, it writes a plaintext pwd to userPassword field as configured by slapd's plaintext hashing method. If I sync the LDAP resource, the syncope user can authenticate using the new password set in PWM, so I assume the password sync went ok. As a check, I see the password appearing plaintext in the CSV output file, as per my configuration and my requirement. I hope the plaintext password got AES encrypted in syncope, but I can't check that? Now, when I push this password to LDAP again, it gets hashed to it's SSHA equivalent as per my LDAP connector configuration: LDAP authentication still works and I have a hashed password in LDAP as I ultimately want, CSV resource still contains the readable password. Then I sync the LDAP SSHA password back to syncope and syncope authentication still works, but now the CSV resource contains the hashed password, where I hoped syncope would have kept the original AES encrypted version of my first setting in PWM. Syncing this password to LDAP back again make LDAP auth still work, so syncope does not rehash the hash as I would have expected based on the hash in CSV resource?! To fix this, syncope or the ldap connector should become a bit more 'intelligent' about when to sync the password (only if it's plaintext or other equivalent of AES, never sync hashed?) just like it is when pushing the hashed password to LDAP. Best regards, Martin On Tue, Oct 28, 2014 at 12:30 PM, Martin van Es wrote: > Hi Francesco, > > I managed to set pwd in PWM (cleartext in LDAP), sync (full reconcile) > to Syncope and (re)propagate the same password SSHA hashed back to > LDAP. > This scenario more or less fulfills my desired test scenario, apart > from the short time the password lives unencrypted in LDAP, but which > is hard to overcome without changing PWM (or slapd). > > I'll try to write-up something for the how-to page. > > Thx for the patient answers and advice! > > Regards, > Martin > > On Tue, Oct 28, 2014 at 8:41 AM, Francesco Chicchiriccò > wrote: >> Hi Martin, >> here's some reply to your questions below. >> >>> This hypothetical excercise would require a 2-way encrypted password setup >>> between OpenLDAP and Syncope. Is this a possible scenario? Would PLAINTEXT >>> Passwords in LDAP be the only solution? >> >> >> With Syncope 1.2.0 you can synchronize encrypted passwords from LDAP or DB >> resource and propagate (using the same cipher algorithm, of course) again to >> other LDAP / DB resources. >> For this to happen, usage of LDAPPasswordSyncActions / DBPasswordSyncActions >> (for synchronization) and LDAPPasswordPropagationActions / >> DBPasswordPropagationActions is required. >> >> Another option could be usage of passthrough authentication, again available >> with Syncope 1.2.0: you have the chance to define, in a relevant Account >> Policy, whether authentication (to Syncope core and console) is to be >> checked against one or more of external resources available. >> >>> I just learned that the connid LDAP connector does not support sync, >>> unless you're using Sun Directory Server Enterprise >>> Edition? Is this true? Is there no sync possible from LDAP? >> >> >> In Syncope two types of synchronizations are supported (more info [1]), full >> (calling SEARCH on connectors to get all existing accounts / groups) and >> incremental (calling SYNC on connectors to get all modified accounts / >> groups since previous synchronization). >> >> The former is not as accurate as latter (for example, it cannot identify any >> delete on external resource) and also not as efficient (at every execution >> the whole content is requested by Syncope). >> >> The ConnId LDAP connector supports actual SYNC operation from former Sun >> DSEE (now Oracle DSEE), OpenDS / OpenDJ and Fedora 389 - and at least the >> latter is actually Open Source ;-) >> >> About OpenLDAP, there is a long-standing open issue [2] at ConnId about >> supporting SYNC - should you be interested in contributing, please join the >> discussion at connid-...@googelgroups.com. >> >>> Of course, I'm looking at NetIQ/eDir/SSPR as a commercial example IdM >>> system for my question. It would be nice if Syncope+OpenLDAP+PWM could do >>> this trick as well ;) >> >> >> Well, should you succeed with a working setup satisfying the requirements >> you have in mind, it would be really nice to host a page on our wiki under >> the "How do I...?" section [3]. >> >> Regards. >> >> [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Synchronization >> [2] https://connid.atlassian.net/browse/LDAP-1 >> [3] >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27841983 >> >> >> On 27/10/2014 22:52, Martin van Es wrote: >>> >>> To answer myself, I thought I could tackle this by setting the >>> password plaintext in LDAP using PWM (using a plain
Re: PWM as password manager
Hi Francesco, I managed to set pwd in PWM (cleartext in LDAP), sync (full reconcile) to Syncope and (re)propagate the same password SSHA hashed back to LDAP. This scenario more or less fulfills my desired test scenario, apart from the short time the password lives unencrypted in LDAP, but which is hard to overcome without changing PWM (or slapd). I'll try to write-up something for the how-to page. Thx for the patient answers and advice! Regards, Martin On Tue, Oct 28, 2014 at 8:41 AM, Francesco Chicchiriccò wrote: > Hi Martin, > here's some reply to your questions below. > >> This hypothetical excercise would require a 2-way encrypted password setup >> between OpenLDAP and Syncope. Is this a possible scenario? Would PLAINTEXT >> Passwords in LDAP be the only solution? > > > With Syncope 1.2.0 you can synchronize encrypted passwords from LDAP or DB > resource and propagate (using the same cipher algorithm, of course) again to > other LDAP / DB resources. > For this to happen, usage of LDAPPasswordSyncActions / DBPasswordSyncActions > (for synchronization) and LDAPPasswordPropagationActions / > DBPasswordPropagationActions is required. > > Another option could be usage of passthrough authentication, again available > with Syncope 1.2.0: you have the chance to define, in a relevant Account > Policy, whether authentication (to Syncope core and console) is to be > checked against one or more of external resources available. > >> I just learned that the connid LDAP connector does not support sync, >> unless you're using Sun Directory Server Enterprise >> Edition? Is this true? Is there no sync possible from LDAP? > > > In Syncope two types of synchronizations are supported (more info [1]), full > (calling SEARCH on connectors to get all existing accounts / groups) and > incremental (calling SYNC on connectors to get all modified accounts / > groups since previous synchronization). > > The former is not as accurate as latter (for example, it cannot identify any > delete on external resource) and also not as efficient (at every execution > the whole content is requested by Syncope). > > The ConnId LDAP connector supports actual SYNC operation from former Sun > DSEE (now Oracle DSEE), OpenDS / OpenDJ and Fedora 389 - and at least the > latter is actually Open Source ;-) > > About OpenLDAP, there is a long-standing open issue [2] at ConnId about > supporting SYNC - should you be interested in contributing, please join the > discussion at connid-...@googelgroups.com. > >> Of course, I'm looking at NetIQ/eDir/SSPR as a commercial example IdM >> system for my question. It would be nice if Syncope+OpenLDAP+PWM could do >> this trick as well ;) > > > Well, should you succeed with a working setup satisfying the requirements > you have in mind, it would be really nice to host a page on our wiki under > the "How do I...?" section [3]. > > Regards. > > [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Synchronization > [2] https://connid.atlassian.net/browse/LDAP-1 > [3] > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27841983 > > > On 27/10/2014 22:52, Martin van Es wrote: >> >> To answer myself, I thought I could tackle this by setting the >> password plaintext in LDAP using PWM (using a plaintext password_hash >> rule in slapd) and then sync it to Syncope and have it set by it's >> SSHA equivalent while propagating the change back to the directory. >> This way, the plaintext password would only exist in LDAP in a small >> time window between syncs? >> >> But alas, I just learned that the connid LDAP connector does not >> support sync, unless you're using Sun Directory Server Enterprise >> Edition? Is this true? Is there no sync possible from LDAP? >> >> Regards, >> Martin >> >> On Mon, Oct 27, 2014 at 7:53 PM, Martin van Es wrote: >>> >>> Hi, >>> >>> I'd like to use PWM for Password Self-service management, but that >>> will only let me set passwords for users in an LDAP server. >>> >>> https://code.google.com/p/pwm/ >>> >>> How would I make (Open)LDAP password leading for all passwords, but >>> keep Syncope for propagating users (including passwords) to target >>> applications? Of course, I could make all client applications >>> authenticate agains LDAP, but that would solve the problem only in >>> application layer and needs suitable applications. I'm trying to see >>> if this problem also has a solution in data layer. >>> >>> This hypothetical excercise would require a 2-way encrypted password >>> setup between OpenLDAP and Syncope. Is this a possible scenario? Would >>> PLAINTEXT Passwords in LDAP be the only solution? Maybe changing PWM >>> so that the password would be AES encrypted into a pwd transport >>> attribute, which could be picked up by Syncope and propagated to LDAP >>> and other applications? >>> >>> Of course, I'm looking at NetIQ/eDir/SSPR as a commercial example IdM >>> system for my question. It would be nice if Syncope+OpenLDAP+PWM could >>> do this trick as well ;) >>
Re: PWM as password manager
Hi Martin, here's some reply to your questions below. This hypothetical excercise would require a 2-way encrypted password setup between OpenLDAP and Syncope. Is this a possible scenario? Would PLAINTEXT Passwords in LDAP be the only solution? With Syncope 1.2.0 you can synchronize encrypted passwords from LDAP or DB resource and propagate (using the same cipher algorithm, of course) again to other LDAP / DB resources. For this to happen, usage of LDAPPasswordSyncActions / DBPasswordSyncActions (for synchronization) and LDAPPasswordPropagationActions / DBPasswordPropagationActions is required. Another option could be usage of passthrough authentication, again available with Syncope 1.2.0: you have the chance to define, in a relevant Account Policy, whether authentication (to Syncope core and console) is to be checked against one or more of external resources available. I just learned that the connid LDAP connector does not support sync, unless you're using Sun Directory Server Enterprise Edition? Is this true? Is there no sync possible from LDAP? In Syncope two types of synchronizations are supported (more info [1]), full (calling SEARCH on connectors to get all existing accounts / groups) and incremental (calling SYNC on connectors to get all modified accounts / groups since previous synchronization). The former is not as accurate as latter (for example, it cannot identify any delete on external resource) and also not as efficient (at every execution the whole content is requested by Syncope). The ConnId LDAP connector supports actual SYNC operation from former Sun DSEE (now Oracle DSEE), OpenDS / OpenDJ and Fedora 389 - and at least the latter is actually Open Source ;-) About OpenLDAP, there is a long-standing open issue [2] at ConnId about supporting SYNC - should you be interested in contributing, please join the discussion at connid-...@googelgroups.com. Of course, I'm looking at NetIQ/eDir/SSPR as a commercial example IdM system for my question. It would be nice if Syncope+OpenLDAP+PWM could do this trick as well ;) Well, should you succeed with a working setup satisfying the requirements you have in mind, it would be really nice to host a page on our wiki under the "How do I...?" section [3]. Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Synchronization [2] https://connid.atlassian.net/browse/LDAP-1 [3] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27841983 On 27/10/2014 22:52, Martin van Es wrote: To answer myself, I thought I could tackle this by setting the password plaintext in LDAP using PWM (using a plaintext password_hash rule in slapd) and then sync it to Syncope and have it set by it's SSHA equivalent while propagating the change back to the directory. This way, the plaintext password would only exist in LDAP in a small time window between syncs? But alas, I just learned that the connid LDAP connector does not support sync, unless you're using Sun Directory Server Enterprise Edition? Is this true? Is there no sync possible from LDAP? Regards, Martin On Mon, Oct 27, 2014 at 7:53 PM, Martin van Es wrote: Hi, I'd like to use PWM for Password Self-service management, but that will only let me set passwords for users in an LDAP server. https://code.google.com/p/pwm/ How would I make (Open)LDAP password leading for all passwords, but keep Syncope for propagating users (including passwords) to target applications? Of course, I could make all client applications authenticate agains LDAP, but that would solve the problem only in application layer and needs suitable applications. I'm trying to see if this problem also has a solution in data layer. This hypothetical excercise would require a 2-way encrypted password setup between OpenLDAP and Syncope. Is this a possible scenario? Would PLAINTEXT Passwords in LDAP be the only solution? Maybe changing PWM so that the password would be AES encrypted into a pwd transport attribute, which could be picked up by Syncope and propagated to LDAP and other applications? Of course, I'm looking at NetIQ/eDir/SSPR as a commercial example IdM system for my question. It would be nice if Syncope+OpenLDAP+PWM could do this trick as well ;) Regards, Martin -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC http://people.apache.org/~ilgrosso/
Re: PWM as password manager
To answer myself, I thought I could tackle this by setting the password plaintext in LDAP using PWM (using a plaintext password_hash rule in slapd) and then sync it to Syncope and have it set by it's SSHA equivalent while propagating the change back to the directory. This way, the plaintext password would only exist in LDAP in a small time window between syncs? But alas, I just learned that the connid LDAP connector does not support sync, unless you're using Sun Directory Server Enterprise Edition? Is this true? Is there no sync possible from LDAP? Regards, Martin On Mon, Oct 27, 2014 at 7:53 PM, Martin van Es wrote: > Hi, > > I'd like to use PWM for Password Self-service management, but that > will only let me set passwords for users in an LDAP server. > > https://code.google.com/p/pwm/ > > How would I make (Open)LDAP password leading for all passwords, but > keep Syncope for propagating users (including passwords) to target > applications? Of course, I could make all client applications > authenticate agains LDAP, but that would solve the problem only in > application layer and needs suitable applications. I'm trying to see > if this problem also has a solution in data layer. > > This hypothetical excercise would require a 2-way encrypted password > setup between OpenLDAP and Syncope. Is this a possible scenario? Would > PLAINTEXT Passwords in LDAP be the only solution? Maybe changing PWM > so that the password would be AES encrypted into a pwd transport > attribute, which could be picked up by Syncope and propagated to LDAP > and other applications? > > Of course, I'm looking at NetIQ/eDir/SSPR as a commercial example IdM > system for my question. It would be nice if Syncope+OpenLDAP+PWM could > do this trick as well ;) > > Regards, > Martin > -- > If 'but' was any useful, it would be a logic operator -- If 'but' was any useful, it would be a logic operator
