[security-dev] Undertow / IdentityManager and Digest Authentication

[Shane Bryzak]

On 01/05/13 23:01, 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.

How is it a hack to use an SPI for the very purpose that it was designed 
for?

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

It's not a farce at all, CredentialHandler implementations are 
*trusted*.  Opening up credential storage for everything to be read via 
the IdentityManager API in my opinion is greatly irresponsible.

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

There's essentially two use cases that we need to support; the first one 
is configuration of credential handlers at the IDM subsystem level, the 
second is configuration at application deployment time. Obviously an 
application-specific CredentialHandler will only be valid for as long as 
the application is deployed.  We most likely need to implement some 
protection for class loader boundaries as you mentioned, but it's early 
days still for the IDM subsystem so these tweaks are to be expected.  
The main thing for now is that we understand the use cases, which I 
believe we already have covered.

What our disagreement boils down to is whether or not we should be 
exposing the raw/secret credential values via the IdentityManager API.  
We could continue going back and forth with essentially the same 
arguments but so far neither of us seem to be swayed one way or the 
other - what I'd like is to hear some opinions from some other people.  
Should we or should we not be making user credentials queryable?