Re: [undertow-dev] AuthenticationMechanismFactory
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