[security-dev] Undertow / IdentityManager and Digest Authentication

Shane Bryzak sbryzak at redhat.com
Wed May 1 05:08:47 EDT 2013

On 01/05/13 18:56, Darran Lofthouse wrote:
> On 01/05/13 09:45, Shane Bryzak wrote:
>> On 01/05/13 16:46, Darran Lofthouse wrote:
>>> but we also have requirements now moving beyond
>>> the account verification step.  As I mentioned before we are now going
>>> to require code related to HTTP authentication in a CredentialHandler
>>> and we are going to require code related to SASL authentication in there.
>> You don't *have* to put HTTP or SASL specific code in the
>> CredentialHandler implementation itself, there are ways to avoid this.
> That is what I am interested in hearing about - the example I am being
> shown as the correct way to do this contains HTTP specific code.

As I mentioned in my very last e-mail (which you wouldn't have read yet 
because I only hit the send button 30 seconds ago ;) the Credentials 
parameter can be used to pass state back from the CredentialHandler to 
the calling code.

> I should also mention, when it comes to the authentication / validation
> there is actually no such thing as a digest credential - what there
> actually is is a response to a challenge, this response will then
> potentially be different for every message received from the remote client.

You'll need to forgive me because my digest-fu is rusty after not having 
used it for a few years, however I don't think this should be a 
problem.  If you can describe:

a) the parameters that go in,
b) the stored "secret" information that we need for the user,
c) the processing that has to occur with a) and b), and
d) the state that goes out,

then I'm certain we can implement this as a CredentialHandler.

>>> Regards,
>>> Darran Lofthouse.
>> [1]
>> http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#d0e1102
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev

More information about the security-dev mailing list