[security-dev] Credential validation and storage

Shane Bryzak sbryzak at redhat.com
Thu Oct 18 02:58:03 EDT 2012 

Absolutely, that's still a problem we need to solve.

On 18/10/12 14:16, Jason Porter wrote:
> 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 at redhat.com 
> <mailto:sbryzak at 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/java/org/picketlink/idm/ldap/internal/LDAPIdentityStore.java
>> [2] 
>> https://github.com/picketlink/picketlink-idm/blob/1.1.0/picketlink-idm-spi/src/main/java/org/picketlink/idm/spi/store/FeaturesMetaData.java
>>
>> 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 at redhat.com 
>>> <mailto:sbryzak at 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 at redhat.com 
>>>>> <mailto:sbryzak at 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/java/org/picketlink/idm/password/PasswordEncoder.java
>>>>>> [2] 
>>>>>> https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/password/internal/SHASaltedPasswordEncoder.java 
>>>>>>
>>>>>> _______________________________________________
>>>>>> security-dev mailing list
>>>>>> security-dev at lists.jboss.org <mailto:security-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>>
>>>>
>>
>>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20121018/a28000e1/attachment-0001.html

More information about the security-dev mailing list