[security-dev] Undertow / IdentityManager and Digest Authentication

[Shane Bryzak]

What PicketLink stores for digests is the latter [1] (in no situation do 
we ever store plain text passwords).  There are essentially two methods 
for validating and managing credentials in the IdentityManager [2] 
(three if you count one extra overloaded method):

void validateCredentials(Credentials credentials);
void updateCredential(Agent agent, Object credential);

There is no API method for retrieving an actual credential value so by 
design credential storage is quite secure.

To briefly summarise how things work for a digest authentication in 
PicketLink; we would pass in an instance of DigestCredentials [3] to the 
IdentityManager.validateCredentials() method, which is essentially a 
wrapper around a Digest [4] (which should look quite familiar).  The 
actual implementation of the validation logic can be found in 
DigestCredentialHandler [5].


[1] 
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/credential/internal/DigestCredentialStorage.java
[2] 
https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/java/org/picketlink/idm/IdentityManager.java
[3] 
https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/java/org/picketlink/idm/credential/DigestCredentials.java
[4] 
https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/java/org/picketlink/idm/credential/Digest.java
[5] 
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/credential/internal/DigestCredentialHandler.java

Shane

On 30/04/13 22:26, Darran Lofthouse wrote:
> As there is going to be an integration layer between Undertow and
> PicketLink IDM I think the main requirement for PicketLink IDM is going
> to be: -
>
>    - Where PLIDM has access to plain text passwords for a specified
> account and using the specified digest algorithm generate the digest for
> the username, realm and password separated by colons.
>
>    - Where PLIDM is storing pre-prepared digests for a specified account
> look up the pre-prepared username, realm, password digest for the
> algorithm specified.
>
> This latter option relates to something I brought up a while ago where a
> single credential could be associated with an account in a number of
> different formats - what this means is that the Digest algorithms can
> potentially go beyond MD5 to use stronger digest algorithms.
>
> The pre-prepared digests do offer some protection but PLIDM would still
> be responsible for storing them securely to provide protection against
> accidental disclosure.  The most important thing however is that we do
> not need the plain text passwords to be passed onto the Undertow or SASL
> classes handling the actual authentication.
>
> Regards,
> Darran Lofthouse.
>
>
> On 30/04/13 12:56, Shane Bryzak wrote:
>> Looks pretty straight forward - what do you need from the PicketLink
>> side for this?  The PLIDM implementation should be quite simple, I can
>> help out with it if required.
>>
>> Shane
>>
>> On 30/04/13 19:24, Darran Lofthouse wrote:
>>> I have been saying for a while that I need to raise a discussion
>>> regarding the verification of Digest based requests against an
>>> IdentityManager.
>>>
>>> At the moment this is predominantly needed for Undertow although there
>>> is also a need for same with SASL.
>>>
>>> The following document describes the proposed use of the Undertow
>>> IdentityManager API and the requirement for the implementation i.e. what
>>> we would need from PicketLink IDM once wrapped in the WildFly integration: -
>>>
>>> https://community.jboss.org/wiki/Undertow-IdentityManager-DigestAuthentication
>>>
>>> The three methods on the IdentityManager interface previously used for
>>> Digest based authentication will all be removed.
>>>
>>> An identity manager that can provide this capability will also be
>>> compatible with SASL based authentication without needing to be aware of
>>> the actual verification requirements within SASL.
>>>
>>> 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
>>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20130430/3920076d/attachment.html