[security-dev] Credential validation and storage

Shane Bryzak sbryzak at redhat.com
Wed Oct 17 18:17:03 EDT 2012


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 

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


More information about the security-dev mailing list