Here is the JIRA:
https://issues.apache.org/jira/browse/SYNCOPE-313
Colm.
On Mon, Feb 11, 2013 at 1:48 PM, Francesco Chicchiriccò <ilgro...@apache.org
> wrote:
> On 11/02/2013 14:45, Colm O hEigeartaigh wrote:
>
>> 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?
>>
>
> Yes, completely.
>
>
> 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.
>>
>
> Regards.
>
> 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/>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
