[security-dev] Undertow / IdentityManager and Digest Authentication

Darran Lofthouse darran.lofthouse at redhat.com
Tue Apr 30 09:29:06 EDT 2013


The 'DigestCredentialStorage' is what we need to store but there will 
need to be potentially different instances of this for different hash 
algorithms so it is not just MD5.

However the current validation is really only implementing a small 
subset of RFC2617 and is causing specifics relating to HTTP Digest 
authentication to leak into the IDM, in addition to that being HTTP 
specific it doesn't cover other closely related / similar mechanisms 
such as SASL Digest.

Maybe an alternative Credential and CredentialHandler could be added to 
mirror the ones suggested for Undertow but to complete the 
implementation we need one of the following: -
  - Access to hashed username, realm, password value.
  - On demand the ability to request that the hashed username, realm, 
password value is pushed into a MessageDigest.

Regards,
Darran Lofthouse.


On 30/04/13 13:58, Shane Bryzak wrote:
> 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
>
>
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>

-- 
Darran Lofthouse - Principal Software Engineer

Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)


More information about the security-dev mailing list