Re: [security-dev] Undertow / IdentityManager and Digest Authentication

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 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. > >