[security-dev] Undertow / IdentityManager and Digest Authentication

[Bill Burke]

On 5/1/2013 10:09 AM, Anil Saldhana wrote:
> 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.

Follow the conversation...geez...Digest isn't the only man that needs to 
create hashes from secrets.

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

Classloading, component boundaries, and config can have a huge effect on 
the design.  If you're not thinking about these things, then you are 
being completely shortsighted and Picketlink will be a failure.

Darren and I have given examples already in this thread.  Maybe you 
should go back and read them....

> If not, we will spend the next 30 years designing the perfect API.
>

Which is why I'm suggesting a fully queryable IDM api which includes 
credentials.  It simplifies things greatly Then you don't have to design 
the perfect API!

Bill

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