[security-dev] Undertow / IdentityManager and Digest Authentication

[Bill Burke]

How could I use IDM API to sign/encrypt an arbitrary set of bytes from 
the private key/secret of the domain?  This isn't verification, but 
relies on information stored in the domain.

On 4/30/2013 11:47 AM, Darran Lofthouse wrote:
> 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
>>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com