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