[security-dev] Undertow / IdentityManager and Digest Authentication

Tue Apr 30 10:06:39 EDT 2013

See my previous email, but this looks to be true!  Its kinda cool 
actually.  If you have a new protocol, you write your own storage and 
handlers and pass them into the IDM at runtime.  Completely separate 
concerns.

On 4/30/2013 9:56 AM, Darran Lofthouse wrote:
> Alternatively - could I plug-in my own Credential types and a
> corresponding CredentialHandler for them?
>
> On 30/04/13 14:47, Darran Lofthouse wrote:
>> Sent my last message using the wrong account so it may arrive but
>> writing again just in case.
>>
>> The Digest Credential is what we need stored but we would potentially
>> need more than one to be stored to cope with different hash algorithms
>> being used.
>>
>> The issue regarding what is currently in PicketLink is that it is
>> causing HTTP specific aspects of Digest authentication to leak into the
>> IDM and at the same time is only implementing a small subset of the
>> RFC2617 specification.  We need access to the same pre-prepared digests
>> for SASL authentication but this is using a slightly different format
>> for the digests that are compared.
>>
>> In addition to this we need the entire messages being exchanged both
>> inbound and outbound to be digested along with these pre-prepared hashes
>> for the purpose of adding integrity protection for the messages
>> exchanged.  There is also a middle ground of providing an appropriate
>> header so that the server can also prove it knows the clients password.
>>
>> This is why we need access to the pre-prepared digest for the chosen
>> algorithm or at the very least an option to request PLIDM pushed it into
>> a MessageDigest instance (Maybe PLIDM provides the MessageDigest and
>> wraps it).
>>
>> Otherwise there is going to be a lot of HTTP specific and SASL specific
>> code to potentially push into an IDM and the IDM is going to have to be
>> much more involved in the actual message exchanges.
>>
>> 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
>>>
>> _______________________________________________
>> 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
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com