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

[Darran Lofthouse]

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.

* 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.

* 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.

* 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.

* 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.

Regards,
Darran Lofthouse.