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/

Reply via email to