[security-dev] Undertow / IdentityManager and Digest Authentication
Bill Burke
bburke at redhat.com
Wed May 1 09:01:52 EDT 2013
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.
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 Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the security-dev
mailing list