[security-dev] Undertow / IdentityManager and Digest Authentication
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
> 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.
JBoss, a division of Red Hat
More information about the security-dev