[security-dev] Undertow / IdentityManager and Digest Authentication

[Darran Lofthouse]

At the moment I think the various Digest specifications is the biggest 
one - it has so many options in it that I feel if we can solve (or at 
least know we are able to) everything in the specs then whatever new 
mechanisms / protocols pop up later should also be solvable.

Just thinking this may also need a look at web services, that may be a 
third protocol with a form of digest.

The other one that I think ties in more with WildFly than being Undertow 
specific is key and trust management but that will be a bigger 
discussion - it has a lot of implications from the connections through 
to the authentication of the user and ideally we would want to avoid 
configuring the same thing in multiple locations.

Regards,
Darran Lofthouse.


On 30/04/13 16:07, Anil Saldhana wrote:
> 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.
>>
>>>
>>>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>