Re: [security-dev] Undertow / IdentityManager and Digest Authentication
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/ja...
[5]
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja...
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