[security-dev] Undertow / IdentityManager and Digest Authentication

Darran Lofthouse darran.lofthouse at jboss.com
Wed May 1 03:03:06 EDT 2013 

The problem I see with this is that the CredentialHandler that gets 
implemented has to take on the task of leaking the Credential, in this 
case I think we should verify on the response message as that is 
generated after the call to verify.

Ideally the Credential I pass into the IDM needs to look similar to the 
one I provided on the initial Undertow article - to be able to generate 
a header to verify the integrity of the message (or even to properly 
implement {SLG}-sess) I need the appropriate hashed value.

Alternatively I may have one additional option for me but I don't think 
it covers Bill's scenario (Also I think other projects may be missing 
from the discussion such as JBossWS although they probably would require 
the same as Bill).

One thing I may be able to do in a CredentialHandler is create the 
appropriate MessageDigest instance and push the pre-prepared digest 
straight into it - this MessageDigest could then be passed to the 
Credential being verified - the calling code could then have access to 
the MessageDigest.  That way the calling code would have what it needs 
without actually being exposed to the stored Credential.

This way the HTTP specific portion of verification can still live 
outside the IDM which I believe is still the correct location for it.

Regards,
Darran Lofthouse.


On 30/04/13 21:54, Shane Bryzak wrote:
> There's two options here; the first one is to store the private key as
> an attribute which then makes it a piece of cake to retrieve the value:
>
> Attribute<PrivateKey> attrib = user.<PrivateKey>getAttribute("mysecret");
> PrivateKey key = attrib.getValue();
>
> The other option is to implement your own CredentialHandler as mentioned
> previously.  The design decision to insulate the actual credential
> values from the API was intentional, and at the moment the only time
> they are exposed to the API is when they are created for the very first
> time.  With there seemingly being a major password hack on the news
> every week it is in our best interest to reduce the number of attack
> vectors that make this kind of thing possible, hence the decoupled
> design.  Also, I don't consider writing your own CredentialHandler
> implementation a hack, in fact we have a quickstart for it as it is
> something we expect many of our developers to have to do themselves.
>
> On 01/05/13 06:20, Bill Burke wrote:
>> 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
>

More information about the security-dev mailing list