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. 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. Sent from my iPhone On Oct 17, 2012, at 16:17, Shane Bryzak <sbryzak(a)redhat.com <mailto:sbryzak@redhat.com>> wrote: > Hi guys, > > 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: > > // Password Management > boolean validatePassword(User user, String password); > > void updatePassword(User user, String password); > > void setPasswordEncoder(PasswordEncoder encoder); > > // Certificate Management > boolean validateCertificate(User user, X509Certificate certificate); > > boolean updateCertificate(User user, X509Certificate certificate); > > Furthermore, in IdentityStore we have these methods which are > essentially identical: > > boolean validatePassword(User user, String password); > > void updatePassword(User user, String password); > > // Certificate Management > boolean validateCertificate(User user, X509Certificate certificate); > > boolean updateCertificate(User user, X509Certificate certificate); > > > 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: > > boolean validateCredential(User user, Credential credential); > > void updateCredential(User user, Credential credential); > > 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: > > 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) > 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 > c) provide pluggable access to the encoding process, to allow the > developer to provide custom behaviour for the encoding. > > Does anyone have any suggestions or thoughts on this? > > Shane > > > [1] > https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... > [2] > https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... > > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org <mailto:security-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/security-dev

I was thinking it would be a composition idea. Probably require some config, but may be worth it. Sent from my iPhone On Oct 17, 2012, at 19:35, Shane Bryzak <sbryzak(a)redhat.com <mailto:sbryzak@redhat.com>> wrote: > 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. > > > On 18/10/12 11:21, Jason Porter wrote: >> 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. >> >> 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. >> >> Sent from my iPhone >> >> On Oct 17, 2012, at 16:17, Shane Bryzak <sbryzak(a)redhat.com >> <mailto:sbryzak@redhat.com>> wrote: >> >>> Hi guys, >>> >>> 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: >>> >>> // Password Management >>> boolean validatePassword(User user, String password); >>> >>> void updatePassword(User user, String password); >>> >>> void setPasswordEncoder(PasswordEncoder encoder); >>> >>> // Certificate Management >>> boolean validateCertificate(User user, X509Certificate >>> certificate); >>> >>> boolean updateCertificate(User user, X509Certificate certificate); >>> >>> Furthermore, in IdentityStore we have these methods which are >>> essentially identical: >>> >>> boolean validatePassword(User user, String password); >>> >>> void updatePassword(User user, String password); >>> >>> // Certificate Management >>> boolean validateCertificate(User user, X509Certificate >>> certificate); >>> >>> boolean updateCertificate(User user, X509Certificate certificate); >>> >>> >>> 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: >>> >>> boolean validateCredential(User user, Credential credential); >>> >>> void updateCredential(User user, Credential credential); >>> >>> 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: >>> >>> 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) >>> 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 >>> c) provide pluggable access to the encoding process, to allow the >>> developer to provide custom behaviour for the encoding. >>> >>> Does anyone have any suggestions or thoughts on this? >>> >>> Shane >>> >>> >>> [1] >>> https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... >>> [2] >>> https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... >>> >>> _______________________________________________ >>> security-dev mailing list >>> security-dev(a)lists.jboss.org <mailto:security-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/security-dev > >

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. Sent from my iPhone On Oct 17, 2012, at 21:29, Shane Bryzak <sbryzak(a)redhat.com <mailto:sbryzak@redhat.com>> wrote: > 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. > > 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. > > [1] > https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... > [2] > https://github.com/picketlink/picketlink-idm/blob/1.1.0/picketlink-idm-sp... > > Shane > > On 18/10/12 12:07, Jason Porter wrote: >> I was thinking it would be a composition idea. Probably require some >> config, but may be worth it. >> >> Sent from my iPhone >> >> On Oct 17, 2012, at 19:35, Shane Bryzak <sbryzak(a)redhat.com >> <mailto:sbryzak@redhat.com>> wrote: >> >>> 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. >>> >>> >>> On 18/10/12 11:21, Jason Porter wrote: >>>> 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. >>>> >>>> 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. >>>> >>>> Sent from my iPhone >>>> >>>> On Oct 17, 2012, at 16:17, Shane Bryzak <sbryzak(a)redhat.com >>>> <mailto:sbryzak@redhat.com>> wrote: >>>> >>>>> Hi guys, >>>>> >>>>> 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: >>>>> >>>>> // Password Management >>>>> boolean validatePassword(User user, String password); >>>>> >>>>> void updatePassword(User user, String password); >>>>> >>>>> void setPasswordEncoder(PasswordEncoder encoder); >>>>> >>>>> // Certificate Management >>>>> boolean validateCertificate(User user, X509Certificate >>>>> certificate); >>>>> >>>>> boolean updateCertificate(User user, X509Certificate >>>>> certificate); >>>>> >>>>> Furthermore, in IdentityStore we have these methods which are >>>>> essentially identical: >>>>> >>>>> boolean validatePassword(User user, String password); >>>>> >>>>> void updatePassword(User user, String password); >>>>> >>>>> // Certificate Management >>>>> boolean validateCertificate(User user, X509Certificate >>>>> certificate); >>>>> >>>>> boolean updateCertificate(User user, X509Certificate >>>>> certificate); >>>>> >>>>> >>>>> 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: >>>>> >>>>> boolean validateCredential(User user, Credential credential); >>>>> >>>>> void updateCredential(User user, Credential credential); >>>>> >>>>> 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: >>>>> >>>>> 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) >>>>> 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 >>>>> c) provide pluggable access to the encoding process, to allow the >>>>> developer to provide custom behaviour for the encoding. >>>>> >>>>> Does anyone have any suggestions or thoughts on this? >>>>> >>>>> Shane >>>>> >>>>> >>>>> [1] >>>>> https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/jav... >>>>> [2] >>>>> https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja... >>>>> >>>>> _______________________________________________ >>>>> security-dev mailing list >>>>> security-dev(a)lists.jboss.org <mailto:security-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/security-dev >>> >>> > >

Actually Darran, Pedro and I were discussing IDM for AS and we felt that the presence of events and event handlers is needed for the credential process. This will allow setting additional hashes as attributes on the User object.

On 18 Oct 2012, at 14:19, Anil Saldhana wrote: > Actually Darran, Pedro and I were discussing IDM for AS and we felt that the presence of events and event handlers is needed for the credential process. This will allow setting additional hashes as attributes on the User object. I would suggest doing this as an SPI (so that an event bus can be plugged in, and we don't provide one), not an API, as CDI already offers an eventing facility and is the way we want to promote people doing events in most cases. _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev