[security-dev] Undertow / IdentityManager and Digest Authentication

[Darran Lofthouse]

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
>