Re: PWM as password manager

2014-11-07 Thread Francesco Chicchiriccò

On 06/11/2014 18:32, Martin van Es wrote:

HI Francesco,

On Thu, Nov 6, 2014 at 5:36 PM, Francesco Chicchiriccò
ilgro...@apache.org 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

2014-11-06 Thread Francesco Chicchiriccò

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òilgro...@apache.org 
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 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.


Re: PWM as password manager

2014-11-06 Thread Martin van Es
Hi Francesco,

On Thu, Nov 6, 2014 at 4:34 PM, Francesco Chicchiriccò
ilgro...@apache.org 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

2014-11-06 Thread Francesco Chicchiriccò

On 06/11/2014 17:17, Martin van Es wrote:

Hi Francesco,

On Thu, Nov 6, 2014 at 4:34 PM, Francesco Chicchiriccò
ilgro...@apache.org 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

2014-11-06 Thread Martin van Es
HI Francesco,

On Thu, Nov 6, 2014 at 5:36 PM, Francesco Chicchiriccò
ilgro...@apache.org 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

2014-10-28 Thread Francesco Chicchiriccò

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/




Re: PWM as password manager

2014-10-28 Thread Martin van Es
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 

PWM as password manager

2014-10-27 Thread Martin van Es
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