[undertow-dev] AuthenticationMechanismFactory

[Bill Burke]

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