Hi Francesco,
This should be instead: "The ability to synchronize non-cleartext passwords
> from external resources sounds like a nice new feature, isn't it?"
>
Yes I think so. I think the passthrough authentication use-case is more
powerful, as I don't see an easy way to support (for example) salting using
this approach. But it should be pretty straightforward to implement, just
treat the retrieved password as hashed according to an algorithm set on the
Connector for the DB Connector, or via "{CIPHER}VALUE" for LDAP, etc. Shall
I create a JIRA for this task?
Colm.
On Tue, Feb 5, 2013 at 2:02 PM, Francesco Chicchiriccò
<[email protected]>wrote:
> On 05/02/2013 13:53, Francesco Chicchiriccň wrote:
>
>> On 05/02/2013 12:48, Colm O hEigeartaigh wrote:
>>
>>> Hi all,
>>>
>>> Just thinking aloud here about how passwords are encoded in Syncope.
>>> Let's
>>> say I have some Users in an SQL backend I want to synchronize into
>>> Syncope.
>>> I want to 'retrieve passwords' in the Connector, as I want to allow users
>>> to call on the 'rest/user/verifyPassword/X.**json?password=Y' API, and
>>> so I
>>> provide an appropriate mapping.
>>>
>>
>> Currently this cannot work: the password value synchronizing from
>> external resource is currently just ignored - a new random policy-compliant
>> password is generated (look at the end of
>> ConnObjectUtil.**getAttributableTO()
>> - called by SyncopeSyncResultHandler.**create()).
>>
>
> Correction: as correctly pointed out by Colm, this happens only if no
> password was provided by the synchronizing resource.
>
>
> If the passwords are stored in the backend in a hashed format then there
>>> is
>>> no way of successfully calling the above API from what I can see. The
>>> 'Password Cipher Algorithm' String of the Connector only applies to the
>>> hashing algorithm used for propagation not for synchronization.
>>> PasswordEncoder.verify() will hash the user password according to
>>> user.getCipherAlgorithm(), and so it will end up hashing the password
>>> twice
>>> in this use-case.
>>>
>>
>> Actually this use case, e.g. authenticating users against an external
>> resource, is covered by SYNCOPE-164 as "passthrough authentication".
>>
>> Does it make sense that if the Connector is configured to hash passwords
>>> on
>>> the propagation side using a given algorithm, that we can have some
>>> internal logic in Syncope that will treat a retrieved password as hashed
>>> according to this algorithm?
>>>
>>
>> Definitely yes: the way how the synchronizing password value is
>> interpreted could also depend on the connector: for example {CIPHER}VALUE
>> for LDAP.
>>
>> The ability to synchronize passwords from external resources sounds like
>> a nice new feature, isn't it?
>>
>
> This should be instead: "The ability to synchronize non-cleartext
> passwords from external resources sounds like a nice new feature, isn't it?"
>
> Regards.
>
> --
> Francesco Chicchiriccň
>
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/<http://people.apache.org/~ilgrosso/>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
