[security-dev] Undertow / IdentityManager and Digest Authentication

Tue Apr 30 16:20:01 EDT 2013

So you're saying that instead of doing straightforward code to get at 
information stored within the IDM to perform a hash a full request or 
response, he has to hack a handler to do it through a verify() call?

Would it be the same if I wanted to sign/encrypt an arbitrary set of 
bytes with a private key/secret stored in the IDM?  I'd have to hack a 
verifier to tunnel this?

I thought we were rewriting these security APIs so that we didn't have 
to do stupid pet tricks anymore?

On 4/30/2013 4:12 PM, Shane Bryzak wrote:
> Yes, you can absolutely do this.
>
>
> On 30/04/13 23:56, 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
>
> _______________________________________________
> 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