[security-dev] Credentials API redesign

[Shane Bryzak]

On 12/06/2012 09:20 PM, Marek Posolda wrote:
> Hi,
>
> I think it may be little confusing for people to have interface 
> "Credential" and interface "LoginCredentials". How about using little 
> different name like "LoginState" for the second one? As the main 
> purpose of the LoginCredentials is to encapsulate whole login state if 
> I understand it correctly (not only secret credentials).

You know what - after thinking about this for a bit, I've come to the 
realization that we probably don't even need the Credential interface.  
It's only a marker interface anyway, and I see no reason why we just 
can't use any class as a credential (and besides, JAAS does it this way 
also [1]).  Removing the Credential interface would eliminate any 
confusion, and in fact I would probably be inclined to just rename 
LoginCredentials to simply Credentials to make things simpler.

[1] 
http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#Credentials

>
> Also I may missed some details, but does it support the use-case when 
> authentication requires multiple steps (handshakes)? For those 
> use-cases, it seems to be more natural to me if CredentialHandler is 
> like this:
>
> public interface CredentialHandler {
>      LoginResult validate(LoginState credentials, IdentityStore store);
>      void update(User user, Credential credential, IdentityStore store);
> }
>
> and returned LoginResult contains some additional info about state 
> (LOGIN_SUCCESS, LOGIN_FAILED, MORE_STEPS_REQUIRED) and possible wrapps 
> User if state is LOGIN_SUCCESS or wrapps other info if the state 
> result was MORE_STEPS_REQUIRED. Maybe LoginState and LoginResult could 
> be single interface... not sure.

We can support this by including the additional state within the 
LoginCredentials instance, however this might not be immediately obvious 
to most developers.  I'll see if we can improve this in some way.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20121206/55763ecb/attachment.html