[undertow-dev] AuthenticationMechanismFactory

Stuart Douglas sdouglas at redhat.com
Sat Dec 14 05:33:20 EST 2013


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


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

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.
> 
> Finally, I'm assuming that <auth-method>Basic, Keycloak,
> SSO</auth-method> will fill up the LoginConfig object thats available in
> DeploymentInfo?  Is it ok for the KeycloakServletExtension to remove
> "KEYCLOAK" from LoginConfig and add two new ones?  Looks like I can,
> just want to make sure any undocumented contract isn't going to be
> enforced in the future.

Yes, that is fine. For the most part everything in DeploymentInfo is mutable.

Stuart

> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 


More information about the undertow-dev mailing list