[undertow-dev] AuthenticationMechanismFactory

[Stuart Douglas]

> 
> On 12/14/2013 5:33 AM, Stuart Douglas wrote:
> >
> >> What does ordering have to do with AuthMechFactory?  Are you planning an
> >> additional META-INF/services mechanism for AuthMechFactorys?  If not,
> >> how does one plug in one?  Via a ServletExtension?  If so, *AGAIN*, what
> >> is the point of the AuthMechFactory when all the construction can be
> >> done within the ServletExtension?
> >
> > Because you can have multiple servlet extensions. This way undertow
> > controls the order. If both extensions just add themselves you have no
> > defined order.
> >
> 
> Again, what does ordering have to do with requiring an AuthMechFactory
> interface?
> 
> MyServletExtension {
>     di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...));
> }
> 
> Why do i need a AuthMechFactory if the servlet extension is able to
> construct the AuthMech?  I just would never use AuthMechFactory as all
> config information is already available within the ServletExtension for
> me to construct the AuthMechanism.  In fact, there's much more metadata
> available within the ServletExtension than is passed to the AuthMechFactory.

Note that with my latest changes you can do exactly what you mention above (di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...));).

I guess the only real thing it buys you is having the ability to configure the same mechanism with different properties, although I am not sure
if that is really something that anyone would ever want to do. 

It also makes reading the config properties easier, as they are passed directly to the factory, although I guess it is pretty easy to just retrieve them directly, especially if I just add a convenience method. 

So maybe it is not really worth having the factory concept, although given that you don't have to use it if you don't want to I am not sure if we should keep it or not.

Stuart


> 
> >
> >>
> >> But, while we're talking about ordering...
> >>
> >> For Keycloak there's an "oauth redirect" mechanism that sends a 302
> >> response back for its challenge.  The way the Undertow logic works now,
> >> if this mechanism isn't first, the 302 status code will never be sent
> >> back, it will never work and you might as well not even list the
> >> mechanism.  Either my ServletExtension can force it to be first by
> >> calling LoginConfig.addFirst(), or it can throw a deployment exception.
> >
> > As long as the mechanism beforehand does not specify a status code, your
> > mechanism should be able to. This is a fundamental limitation of HTTP, and
> > it does limit which mechanisms can be combined.
> >
> 
> Multiple WWW-Authenticate headers are allowed i'm just not sure what a
> user-agent would do if it saw a code other than 401 with a response that
> contained these headers.
> 
> > Basically some mechanisms are never going to be able to work together.
> >
> >>
> >> BTW, I'm also not sure if you combine a 302 and a WWW-Authenticate it
> >> won't confuse the User-Agent.  Maybe the ChallengeResult should specify
> >> whether iteration of the mechanisms should continue.
> >>
> 
> Again, it would be great if a ChallengeResult could abort the
> sendChallenge loop.  It would suck if there was no workaround for cases
> that were sensitive to a strict response.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>