[security-dev] Undertow / IdentityManager and Digest Authentication
darran.lofthouse at jboss.com
Tue Apr 30 11:47:46 EDT 2013
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.
On 30/04/13 16:07, Anil Saldhana wrote:
> 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. :)
> 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
>> 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
>>> 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
More information about the security-dev