[undertow-dev] AuthenticationMechanism, ChallengeResult and Response Code

[Stuart Douglas]

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

So basically you want a way to end the process from the sendChallenge() method?

If so you can basically already doing this by just invoking the HttpServerExchange.endEchange() method 

This is not handled super well at the moment though, as the other mechanisms will still be tried, they just cant do anything as the response has been committed. We should do something about this.  

Stuart

> 
> 
> Bill
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>