[security-dev] Undertow / IdentityManager and Digest Authentication

[Darran Lofthouse]

On 30/04/13 15:05, Bill Burke wrote:
> 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.

Really in this case it is not really a simple relationship of one 
credential type to one protocol handler.

We may be able to get multiple representation of the same credential 
into one Credential class e.g. we could have one NewDigestCredential 
that can store the MD5 version in addition to a SHA-256 version.

However this NewDigestCredential would need to be used by both a 
HTTPDigestCredentialHandler and a SASLDigestCredentialHandler.

Should add this does not cover another option we have with Digest 
authentication where the first round trip between the client and server 
established effectively a shared key based off the stored credential - 
for all future interactions with the client authentication is based on 
this shared key as long as it is valid and not the stored credentials.

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

That may be an option for the inbound message, we need to read the 
message from the client to be able to create it's digest and still have 
the message available for the final HttpHandler to be able to read it.

However this does not cover the outbound response message where the 
whole response also needs to be digested.

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

Remember this is not just Undertow - this is Undertow and SASL - both of 
which need verification and header generation based on the same stored 
credentials.

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

As I mentioned on my other reply, a secure mechanism to have the stored 
credential pushed into a MessageDigest may also be suitable.

>

Another alternative I could just implement an 
UndertowDigestCredentialHandler that handles the DigestCredential from 
my original article and calls the verifyHA1() this would give me the 
hash I require for the subsequent operations and validation of the message.

>
>