[security-dev] Undertow / IdentityManager and Digest Authentication

[Bill Burke]

On 4/30/2013 9:47 AM, 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.
>

Are you sure there is a leakage here?  That was my fear at first, but it 
looks as though this isn't true.  Review these again:

[1] 
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/credential/internal/DigestCredentialStorage.java

[5] 
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/credential/internal/DigestCredentialHandler.java

You'd just write additional handlers and storage classes for your 
specific protocols (i.e. SASL).  These objects can be provided to 
Picketlink IDM *at runtime* correct?  So doesn't look like there is any 
leakage as your Undertow protocol handler would be providing the 
callback objects.

> 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.
>

Couldn't you store the Http Request, byte[] of full message inside the 
Credentials parameter passed into the Handler's verify method?  You have 
to cache the message anyways so that the application can obtain what it 
needs.

> 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.
>

Again, I don't think this is true because the Undertow Digiest 
Authenticator can produce the appropriate handlers, no?  Maybe Shane 
should review why they have what they have?  In a previous email thread 
he talked a bit about chained IDMs where one or all may have to verify a 
credential.  Also, maybe an option to query storage directly should be 
available from Picketlink IDM API (if there isn't one already).  The 
keeps both metadata and verification separate concerns, IMO.



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