[security-dev] PicketLink 3 - IDM API - Credential Management

[Shane Bryzak]

On 12/01/2012 09:55 PM, Darran Lofthouse wrote:
> I am currently looking into using the IDM API as I am authenticating
> some HTTP requests and I am running into a couple of questions, the
> aspect of the API I am currently looking at is: -
>
>       // Credential management
>       boolean validateCredential(User user, Credential credential);
>       void updateCredential(User user, Credential credential);
>
> Correct me if I am wrong as it is the foundation of what I am thinking
> about but I am seeing the 'validateCredential' as the method to call to
> validate that the Credential supplied by the user is valid so that we
> can verify the user is who they claim to be.
>
> There is quite a lot below so it may make sense to subsequently break
> these out into their own discussions.
>
> * Userless Validation *
>
> As mentioned on the other thread something I would find really useful is
> something along the lines of: -
>
>       User validateCredential(Credential credential);
>
> This would be for situations where there is a direct mapping from the
> Credential to the user it relates to, my main example being a
> X509Certificate.
>
> I am looking at this from the perspective of - The IDM is already
> managing the association of User to Certificate so to call
> validateCredential I would see it as better that the calling code is not
> forced to map it to the user first.

Keep in mind that the credential validation and management features 
provided by the IDM API are totally optional.  There's nothing 
preventing anyone from writing their own custom authentication logic 
which is capable of interacting with the IDM identity model but doesn't 
necessarily depend on its credential validation.  In fact, the 
authentication API in PicketLink Core is designed this way from the 
ground up - IDM credential validation will only be used if a) IDM has 
been configured in the application, and b) a custom validator hasn't 
already been provided - so IDM password-based authentication is only 
ever used as a last resort.  With this in mind, and considering the 
bazillion different possibilities when it comes to authentication I'd 
like to suggest that we perhaps restrict IDM-based authentication to the 
simplest possible use case, i.e. username/email and password.

Having said all that though, we probably need to review the credential 
management methods that we currently provide.  I'm guessing that for 
certificate-based authentication (I'm a little rusty on this) we would 
have to store some kind of custom credentials against the User, in which 
case the current API for credential management doesn't actually support 
reading any of the credential values that might be required by a custom 
authenticator.



>
> * Multiple Credentials *
>
> The validateCredential method potentially allows many different types of
> Credential to be used - however the updateCredential method seems to
> apply a 1:1 mapping of User and Credential.
>
> I can see situations where a user would have multiple Credentials, an
> immediate example being both a Password and a X509Certificate.

This is an implementation detail - all IdentityStore implementations 
should support the storing of multiple credential types.  Out of the box 
we support PasswordCredential, DigestCredential and 
X509CertificateCredential and two separate calls to updateCredential() 
with different credential types should persist both credentials.


>
> * Ambiguous Meaning to Credentials *
>
> This is just something I am not as clear on how the two relate and think
> it has the potential to be confusing using the same Credential interface
> for validation and for association with the user.
>
> For Credentials such as the PasswordCredential and
> X509CertificateCredential these do make sense to both be validated and
> associated.
>
> But then there are Credentials like the DigestCredential which only make
> sense to be validated but not associated.

Agreed, we need to fix this.

>
> * Multiple Representations of Same Credential *
>
> Another requirement I may have is storing multiple representations of
> the same Credential against the same user - this is just thinking out
> loud at the moment so not sure if this would be a responsibility of the
> IdentityStore.
>
> The situation here is that the user has one password but we want to
> support two different hashes with Digest authentication - if we want to
> choose to pre-hash the password with the username and realm we would
> need to do that once per type of hash supported.
>
> The benefit of pre-hashing in this way is that if the user has used the
> same password but for a different realm someone gaining access to the
> hashed form does not necessarily get access to all of that users accounts.

I'm not quite sure I understand this one.  In the latest design of the 
identity model, a User belongs to a single Realm.  What's the definition 
of a realm in the context of your use case?

>
> * Access To The Credential *
>
> The next issue is where access to the credential is required or at the
> very least something is needed to be generated from the credential -
> this is used in client/server scenarios where the server also proves to
> the client that it knows the users password.
>
> Keeping the Credential so that it can not be retrieved from the IDM is
> good but it does open up the need to be able to generate some response
> values within the IDM based on additional information supplied.
>
> The example I currently have is regarding Digest authentication, I have
> a need for the following two hashes to be generated: -
>
> "username : realm : password"
> "username : realm : password : nonce : cnonce"
>
> The first could be the pre-hashed password I mention above but the
> second definitely needs generating on demand as we have both the nonce
> that was generated from the server and the nonce the client has sent to
> challenge the server.

+1, as I stated above we need to review the credential management API, 
which since the start of this project has remained relatively 
untouched.  I'll spend some time working on this over the next couple of 
days to come up with a better design.


>
> Regards,
> Darran Lofthouse.
>
>
>
>
>
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev