Re: Password encoding query
Done! Colm. On Thu, Feb 14, 2013 at 2:12 PM, Francesco Chicchiriccò ilgro...@apache.org wrote: On 14/02/2013 15:09, Colm O hEigeartaigh wrote: Here is the JIRA: https://issues.apache.org/**jira/browse/SYNCOPE-313https://issues.apache.org/jira/browse/SYNCOPE-313 Thanks: which fix version should we set for this? 1.2.0? Roadmap [1] should be updated accordingly, then. Regards. [1] https://cwiki.apache.org/**confluence/display/SYNCOPE/**Roadmaphttps://cwiki.apache.org/confluence/display/SYNCOPE/Roadmap -- 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
Re: Password encoding query
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.orgwrote:
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
Re: Password encoding query
On 14/02/2013 15:09, Colm O hEigeartaigh wrote: Here is the JIRA: https://issues.apache.org/jira/browse/SYNCOPE-313 Thanks: which fix version should we set for this? 1.2.0? Roadmap [1] should be updated accordingly, then. Regards. [1] https://cwiki.apache.org/confluence/display/SYNCOPE/Roadmap -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Password encoding query
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.orgwrote:
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/
Password encoding query
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. 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. 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? Colm. -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
Re: Password encoding query
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()).
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?
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Password encoding query
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/
