[security-dev] Undertow / IdentityManager and Digest Authentication

[Anil Saldhana]

On 05/01/2013 08:01 AM, Bill Burke wrote:
> On 5/1/2013 5:08 AM, Shane Bryzak wrote:
>> >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.
>> >
> Sure you can implement it.  I think we've proved with JAAS that you can
> basically hack whatever you need.  But What you're describing Shane is a
> hack to get around the inadequacies of the IDM API.  If it is possible
> to pass state via the credentials object, then this credential
> protection you speak of is a total and utter farse that just complicates
> the API.
Digest Authentication semantics makes it complex.  It is the odd man out.
> So, basically, we're going to have to write protocol-specific Credential
> and CredentialHandlers, correct?  How will this look at deployment time?
>    At runtime?  Who registers the Handlers and the Credential->Handler
> mapping?  The IDM Subsystem config?  The domain config?  The web-app
> config?  All the above have an effect on class loader boundaries and the
> set up and configuration of class Modules and class loader visibility.
Bill- the IDM subsystem is far down in the chain.  It cannot start thinking
about the config happening in the web container and integrating layers.  You
should definitely provide some examples via some pictures for the people on
the list. That way we get on the same page.

If not, we will spend the next 30 years designing the perfect API.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20130501/11c6bd9c/attachment-0001.html