Re: [undertow-dev] AuthenticationMechanismFactory
On 12/13/2013 4:02 PM, Stuart Douglas wrote:
The reason why this is better that just adding you auth mechanism is
because Undertow now controls the order. In the old
way of doing things if the user had specified something like:
BASIC?silent=true,KEYCLOAK,SSO
There is simply no way for extensions to parse that string and install themselves in the
correct order (and order is very important). For one thing all the extension have to parse
it in the exact same way, but more importantly because there is no ordering between
extensions, there is no reliable way for an extension to figure out where it has to insert
itself in the mechanism list.
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?
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.
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com