[security-dev] Undertow / IdentityManager and Digest Authentication

[Shane Bryzak]

On 01/05/13 17:03, Darran Lofthouse wrote:
> The problem I see with this is that the CredentialHandler that gets
> implemented has to take on the task of leaking the Credential, in this
> case I think we should verify on the response message as that is
> generated after the call to verify.
>
> Ideally the Credential I pass into the IDM needs to look similar to the
> one I provided on the initial Undertow article - to be able to generate
> a header to verify the integrity of the message (or even to properly
> implement {SLG}-sess) I need the appropriate hashed value.
>
> Alternatively I may have one additional option for me but I don't think
> it covers Bill's scenario (Also I think other projects may be missing
> from the discussion such as JBossWS although they probably would require
> the same as Bill).
>
> One thing I may be able to do in a CredentialHandler is create the
> appropriate MessageDigest instance and push the pre-prepared digest
> straight into it - this MessageDigest could then be passed to the
> Credential being verified - the calling code could then have access to
> the MessageDigest.  That way the calling code would have what it needs
> without actually being exposed to the stored Credential.

This is definitely how I would recommend implementing this scenario.  
The Credentials object that is passed into CredentialHandler.validate() 
is a great place to pass state back and forth between the 
CredentialHandler and the caller.

>
> This way the HTTP specific portion of verification can still live
> outside the IDM which I believe is still the correct location for it.
>
> Regards,
> Darran Lofthouse.
>
>
> On 30/04/13 21:54, Shane Bryzak wrote:
>> There's two options here; the first one is to store the private key as
>> an attribute which then makes it a piece of cake to retrieve the value:
>>
>> Attribute<PrivateKey> attrib = user.<PrivateKey>getAttribute("mysecret");
>> PrivateKey key = attrib.getValue();
>>
>> The other option is to implement your own CredentialHandler as mentioned
>> previously.  The design decision to insulate the actual credential
>> values from the API was intentional, and at the moment the only time
>> they are exposed to the API is when they are created for the very first
>> time.  With there seemingly being a major password hack on the news
>> every week it is in our best interest to reduce the number of attack
>> vectors that make this kind of thing possible, hence the decoupled
>> design.  Also, I don't consider writing your own CredentialHandler
>> implementation a hack, in fact we have a quickstart for it as it is
>> something we expect many of our developers to have to do themselves.
>>
>>