[undertow-dev] AuthenticationMechanism, ChallengeResult and Response Code

[Darran Lofthouse]

Thanks for the clarification Bill.

So in your case we know in advance that there is a single mechanism 
which should be the only mechanism sending challenges and at least one 
more mechanism that can perform the authentication without the need to 
send challenges.

I am just wondering for this scenario if we can handle this better 
during registration of the mechanisms rather than at runtime processing 
a request.

Regards,
Darran Lofthouse.


On 20/12/13 00:12, Bill Burke wrote:
>
> On 12/19/2013 12:13 PM, Darran Lofthouse wrote:
>> Coming back to this topic ;-)
>>
>> The reasons I believe it is the authenticate method that should signal a
>> mechanism wants exclusivity in sending a challenge are: -
>>
>> 1 - This method already returns one of three values to indicate it's
>> authentication state, adding one more value to indicate that a mechanism
>> has started authentication but wants exclusivity would fit with this.
>>
>> 2 - The mechanism doesn't need to be first just to be able to request
>> exclusivity - also not going to cause a complication if another
>> mechanism had added it's challenge as that would not be able to happen.
>>
>> 3 - In general we should try and avoid writing mechanism that only work
>> alone (depending on various constraints), having a sendChallenge that
>> always requested exclusivity would go against this - whereas a mechanism
>> detecting it wants exclusivity in the authenticate stage would be valid
>> as remaining mechanisms would still be usable for the times it does not
>> request exclusivity.
>>
>
> #3 just doesn't work for me.
>
> I have two mechanisms for keycloak:
>
> A) Bearer token mechanism that uses the Authorization header and
> challenges with a 401 and WWW-Authenticate
> B) OAuth browser redirection mechanism, that challenges with a 302 and a
> Location header.  This is a redirect to the authentication server where
> it will display a login form.
>
> Mechanism (B) will not ever request exclusivity during the authenticate
> phase because keycloak also allows for (A) in the same deployment.
> Mechanism (B) will not ever be able to challenge if it can't set a 302
> response code.  I worry that if other mechanisms add WWW-Authenticate
> headers to a 302 response, it may confuse the user-agent, but this worry
> might be bogus.
>
> So, I don't agree with #3's statement that "having sendChallenge that
> always requested exclusivity would go against this".  Mechanism (B)
> works with a other mechanisms as long as the user-agent is doing
> preemptive authentication.
>
> Whether Keycloak is successful or not is besides the point.  The use
> case where an auth mechanism needs to redirect to another machine to
> display a login form is a valid one.
>
>
> Bill
>