Another area that I want to comment on is authentication mechanisms, I
know the proposal has not been written yet but the current approach
within the project seems to be to follow the ServerAuthModule style.
One big thing we have learned within JBoss / Wildfly is that
administrators of enterprise installations no longer want to be
restricted to single authentication mechanisms for a deployment /
context - instead there is strong demand for multiple mechanisms to be
offered concurrently.
This does have limitations as there are some combinations that can never
work together but at the same time there are mechansism that can be
combined. The most common combination I really see is CLIENT_CERT, plus
SPNEGO, plus some form of username/password authentication. There is
also the potential that multiple username/password mechanisms can be
offered so the browser can select which one it supports - with current
renewed progress with the HTTP authentication RFCs I would really
suspect we will see demand for this later case as it takes time for web
browsers to catch up and for users to upgrade.
The side effect of this is that we have found having a single method on
a mechanism to handle everything about it's authentication does not work
- instead we need to split this up into two phases so all mechanisms can
have an opportunity to inspect the incoming request and then after an
authentication decision has been made some or all of the mechanism
implementations can be given an opportunity to add their response.
We first handled this within Undertow whereby a mechanism provides and
implementation of two different methods, one for the request handling
phase and one for the response handling phase: -
https://github.com/darranl/undertow/blob/master/core/src/main/java/io/undertow/security/api/AuthenticationMechanism.java
This has a couple of downsides, the first being that it is difficult to
share state between the request and response side of the call, the
second being that we need a special return type just to handle the
situation that we need to return two pieces of information.
With our work designing a generic non-web server specific API we have
revisited this again for WildFly Elytron and evolved this principal
further: -
https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/http/HttpServerAuthenticationMechanism.java
Now the mechanism is only required to implement a method to handle the
request phase - however on the request object passed into this call we
have four methods that the mechanism can call to indicate the result of
it handling that request (noAuthenticationInProgress,
authenticationInProgress, authenticationFailed, badRequest).
https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/java/org/wildfly/security/http/HttpServerRequest.java
For each of these methods the mechanism can optionally pass in a
responder to handle the response phase of the flow - this makes it a lot
easier to share state between request and response and also means
mechanisms only need to implement response handling if it is part of
their normal flow.
Regards,
Darran Lofthouse.