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

[Darran Lofthouse]

On 12/02/2012 11:09 PM, Shane Bryzak wrote:
> On 12/01/2012 09:55 PM, Darran Lofthouse wrote:
>> * 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.

That could be useful, from an AS7 perspective and a HTTP authentication 
perspective we have a lot of complex scenarios - however this would mean 
that we would need to be able to access the underlying Credential(s) 
associated with a user - would that be possible?

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