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 <mrva...@gmail.com> 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ò
<ilgro...@apache.org> 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 <mrva...@gmail.com> 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/
