[security-dev] PicketLink IDM - Replace Default Credential Handler

[Darran Lofthouse]

Actually maybe don't ignore this ;-) - I think there is still a scenario 
that could be handled within PicketLink IDM.

Say a user is stored with a pre-prepared hash of their username, realm 
name and password in preparation for possible Digest authentication.

If a UsernamePasswordCredentials object is passed in for validation no 
CredentialHandler will be able to validate it even though all of the 
information is available to perform the validation - the default 
CallbackHandler will be called even though there may be another 
CredentialHandler that does understand how to perform the validation 
based on the Credentials associated with the Agent.

Regards,
Darran Lofthouse.


On 21/06/13 16:30, Darran Lofthouse wrote:
> Actually ignore this, it looks like I may be better off with a new
> CredentialHandler implementation and a complete set of new Credentials.
>
> Regards,
> Darran Lofthouse.
>
>
> On 21/06/13 16:02, Darran Lofthouse wrote:
>> Investigating SASL integration with PicketLink IDM shows the Plain
>> mechanism working fine with a fairly default set up - however as I am
>> adding support for the Digest based mechanism I seem to need to be able
>> to replace the default CredentialHandler for UsernamePasswordCredentials.
>>
>> On validating a request I don't believe that the code making use of the
>> IDM should be aware of any of the storage details, so now I have users
>> that could be stores with a plain text password or a pre-prepared ha1 hash.
>>
>> What I would like is to add one CredentialHandler that can handle
>> requests to validate both plain text passwords and digest credentials
>> and decide internally how to handle them based on which one is currently
>> associated with the agent.
>>
>> My credential handler is registered as it allows me to add my new custom
>> DigestPassword credential but it is not being used for the validation of
>> a UsernamePasswordCredentials object.
>>
>> Is there anything else I need to do to disable the default implementation?
>>
>> Regards,
>> Darran Lofthouse.
>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>