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ò
 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 Martin van Es
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

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

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

2014-11-05 Thread Martin van Es
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

2014-11-03 Thread Francesco Chicchiriccò

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

2014-11-02 Thread Martin van Es
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

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

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