Hi Francesco,
do you mean opening another improvement issue, besides SYNCOPE-164, for
> synchronizing non-cleartext passwords?
>
Yes. I see them as separate use-cases. This task is to synchronize
(non-cleartext) passwords into Syncope, passthrough authentication is to
delegate user authentication to the backend resource. Do you agree with
this distinction?
>
> I agree with this but I don't see it as particularly straightforward:
> consider for example that we cannot refer to any specific connector bundle
> from inside the SyncopeSyncResultHandler, hence we should find the cleanest
> place to encapsulate the following logic:
Yep, good point.
Colm.
On Mon, Feb 11, 2013 at 1:17 PM, Francesco Chicchiriccò <ilgro...@apache.org
> wrote:
> On 11/02/2013 13:30, Colm O hEigeartaigh wrote:
>
>> 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?
>>
>
> Hi Colm,
> do you mean opening another improvement issue, besides SYNCOPE-164, for
> synchronizing non-cleartext passwords?
>
> I agree with this but I don't see it as particularly straightforward:
> consider for example that we cannot refer to any specific connector bundle
> from inside the SyncopeSyncResultHandler, hence we should find the cleanest
> place to encapsulate the following logic:
>
> if (password.isClearText()) {
> // do as currently done
> } else {
> if (connector.isLDAP()) {
> // extract cipher and value
> } else if (connector.isDBTable()) {
> // treat value as ciphered with the cipher defined in connector
> configuration
> } else {
> ...
> }
> }
>
> Regards.
>
> On Tue, Feb 5, 2013 at 2:02 PM, Francesco Chicchiriccò
>> <ilgro...@apache.org>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/>
>
>
