[security-dev] Undertow / IdentityManager and Digest Authentication

Bill Burke bburke at redhat.com
Tue Apr 30 10:05:07 EDT 2013

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:



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 

> 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

More information about the security-dev mailing list