<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Absolutely, that's still a problem we
need to solve.<br>
<br>
On 18/10/12 14:16, Jason Porter wrote:<br>
</div>
<blockquote
cite="mid:876B32F4-A18A-4C1F-A5DD-EA40A598CD85@gmail.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>Fair enough. We will need a method or something to sync what
comes back from SSO, OAuth etc with what is being stored locally
though, which is something we don't have currently. <br>
<br>
Sent from my iPhone</div>
<div><br>
On Oct 17, 2012, at 21:29, Shane Bryzak <<a
moz-do-not-send="true" href="mailto:sbryzak@redhat.com">sbryzak@redhat.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Ok I've thought about this now
;) I think that the only use cases it is relevant for is
those where the credentials are actually stored by the
application. In the SSO, OAuth etc use cases the
authentication path doesn't touch identity management beyond
the possible synchronization of User attributes. For
standard IDM based authentication (anything where the
application manages credentials itself) I think it really is
a responsibility of the IdentityStore. Take LDAP for
example - authentication is performed by binding to the
directory (see the validatePassword() method in [1]), which
requires a tight coupling with the IdentityStore
configuration. This requirement is also shared by
JPAIdentityStore, which may be configured to store user
credentials in the same table as the User record itself.<br>
<br>
I think that partitioning is a valid point (i.e. being able
to mix and match identities as you suggested) however we can
do that by providing something like the Features metadata
feature from PicketLink 1.x (see [2]) which allows us to
configure multiple IdentityStore implementations in a single
application, each providing a certain subset of features.<br>
<br>
[1]
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<a moz-do-not-send="true"
href="https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/ldap/internal/LDAPIdentityStore.java">https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/ldap/internal/LDAPIdentityStore.java</a><br>
[2]
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<a moz-do-not-send="true"
href="https://github.com/picketlink/picketlink-idm/blob/1.1.0/picketlink-idm-spi/src/main/java/org/picketlink/idm/spi/store/FeaturesMetaData.java">https://github.com/picketlink/picketlink-idm/blob/1.1.0/picketlink-idm-spi/src/main/java/org/picketlink/idm/spi/store/FeaturesMetaData.java</a><br>
<br>
Shane<br>
<br>
On 18/10/12 12:07, Jason Porter wrote:<br>
</div>
<blockquote
cite="mid:82E11878-04AF-404D-A8CC-DA90B1B9E710@gmail.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div>I was thinking it would be a composition idea. Probably
require some config, but may be worth it. <br>
<br>
Sent from my iPhone</div>
<div><br>
On Oct 17, 2012, at 19:35, Shane Bryzak <<a
moz-do-not-send="true" href="mailto:sbryzak@redhat.com">sbryzak@redhat.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">That's an interesting idea,
I don't know if it would have limitations (my first
reaction is to think that we require tight coupling
with IdentityStore) however it certainly has some
merit. Let me think about it for a bit.<br>
<br>
<br>
On 18/10/12 11:21, Jason Porter wrote:<br>
</div>
<blockquote
cite="mid:A99EEDEA-533B-454C-9834-2BD4408D05FC@gmail.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div>This sounds good, but I'm wondering if we should
have this extracted completely from the
IdentityStore and have it be its own interface. The
main reason being it would make it easier to mix and
match identities (users, rolls and groups) and
authentication.</div>
<div><br>
</div>
<div>You could have an sso solution, multi-factor,
oauth, etc but still keep the rest of the data in
your RDBMS, ldap, jcr etc. Yes I understand they'd
simply have to create their own impl and many
probably will, but if we ship with reasonable
implementations they can more easily mix and match
and keep things DRY.<br>
<br>
Sent from my iPhone</div>
<div><br>
On Oct 17, 2012, at 16:17, Shane Bryzak <<a
moz-do-not-send="true"
href="mailto:sbryzak@redhat.com">sbryzak@redhat.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
Hi guys,<br>
<br>
I'd like to simplify the Identity Management API a
bit where credentials are concerned. At the
moment we have the following methods defined by
the IdentityManager interface:<br>
<br>
// Password Management<br>
boolean validatePassword(User user, String
password);<br>
<br>
void updatePassword(User user, String
password);<br>
<br>
void setPasswordEncoder(PasswordEncoder
encoder);<br>
<br>
// Certificate Management<br>
boolean validateCertificate(User user,
X509Certificate certificate);<br>
<br>
boolean updateCertificate(User user,
X509Certificate certificate);<br>
<br>
Furthermore, in IdentityStore we have these
methods which are essentially identical:<br>
<br>
boolean validatePassword(User user, String
password);<br>
<br>
void updatePassword(User user, String
password);<br>
<br>
// Certificate Management<br>
boolean validateCertificate(User user,
X509Certificate certificate);<br>
<br>
boolean updateCertificate(User user,
X509Certificate certificate);<br>
<br>
<br>
What I'd like to do is make this a little more
abstract (and more future proof) by replacing
these methods (in both interfaces) with the
following two methods:<br>
<br>
boolean validateCredential(User user,
Credential credential);<br>
<br>
void updateCredential(User user, Credential
credential);<br>
<br>
Once the method invocation hits the IdentityStore
implementation, we have a choice as to what we
want to do here. I think the best option is to go
with a credential encoding API based on the work
that Pedro has already done (see [1] and [2]). My
only suggestion would be to:<br>
<br>
a) make it a little more generic (we should use a
factory object or something to provide the
IdentityStore implementation with the correct
encoder based on the type of credential) <br>
b) provide the encoder implementation with an
invocation context containing a reference back to
the calling IdentityStore to allow access to its
internal methods and/or other state, and<br>
c) provide pluggable access to the encoding
process, to allow the developer to provide custom
behaviour for the encoding.<br>
<br>
Does anyone have any suggestions or thoughts on
this?<br>
<br>
Shane<br>
<br>
<br>
[1]
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<a moz-do-not-send="true"
href="https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/java/org/picketlink/idm/password/PasswordEncoder.java">https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/java/org/picketlink/idm/password/PasswordEncoder.java</a><br>
[2]
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<a moz-do-not-send="true"
href="https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/password/internal/SHASaltedPasswordEncoder.java">https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/password/internal/SHASaltedPasswordEncoder.java</a>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>security-dev mailing list</span><br>
<span><a moz-do-not-send="true"
href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a></span><br>
<span><a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/security-dev">https://lists.jboss.org/mailman/listinfo/security-dev</a></span><br>
</div>
</blockquote>
</blockquote>
<br>
<br>
</div>
</blockquote>
</blockquote>
<br>
<br>
</div>
</blockquote>
</blockquote>
<br>
<br>
</body>
</html>