[security-dev] Undertow / IdentityManager and Digest Authentication

[Anil Saldhana]

Darran,
   if there is anything you find missing in PL IDM from UT perspective, 
please mention it here. The earlier the better considering PL3 is 
scheduled for June. :)

Regards,
Anil

On 04/30/2013 09:48 AM, Darran Lofthouse wrote:
> 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.
>
>>
>>