Hi,
On Tue, Jan 26, 2016 at 12:16 PM, Darran Lofthouse <
darran.lofthouse_at_redhat.com> wrote:
> 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.
>
Absolutely, and it's actually a many-dimensional problem.
The first dimension is the fact that you'd like users to choose between
multiple mechanisms. Most common thing I see is a choice between
email/password and various social networks. E.g. it's what we created here:
https://zeef.com/login and what SO does here:
https://stackoverflow.com/users/login there's an interesting discussion
about it here:
http://meta.stackexchange.com/questions/246689/new-year-new-experiment-login-and-signup-ui
Then the second dimension is indeed "stacking" mechanisms. JASPIC
theoretically has support for that. It's what the ServerAuthContext is
supposed to be doing. The problem with JASPIC here is that it never has
been specified exactly how this stacking should work. There's an example in
Picketbox though, see
http://grepcode.com/file/repo1.maven.org/maven2/org.picketbox/picketbox/4.9.2.Final/org/jboss/security/auth/message/config/JBossServerAuthContext.java#139
I've experimented a little with this for OnmiSecurity as well. It has a
builder API where you can do stuff like this:
AuthStacks stacks = new AuthStacksBuilder() .stack() .name("jsf-form")
.setDefault() .module() .serverAuthModule(new OmniServerAuthModule())
.controlFlag(REQUIRED) .option(PUBLIC_REDIRECT_URL, "/login") .add() .add()
.stack() .name("social-authentication-facebook") .module()
.serverAuthModule(new SocialServerAuthModule(
SocialAuthProvider.facebook.name())) .controlFlag(REQUIRED)
.options(socialOptions) .add() .add()
.build();
This would create 2 stacks where the user can choose from, with each stack
having a single module (SAM aka authentication mechanism).
You could also do:
AuthStacks stacks = new AuthStacksBuilder() .stack() .name("jsf-form")
.setDefault() .module() .serverAuthModule(new OmniServerAuthModule())
.controlFlag(REQUIRED) .option(PUBLIC_REDIRECT_URL, "/login") .add() .add()
.module() .serverAuthModule(new HeaderFallbackAuthModule())
.controlFlag(SUFFICIENT) .option("name", "fallback-header") .add() .add()
.stack() .name("social-authentication-facebook") .module()
.serverAuthModule(new SocialServerAuthModule(
SocialAuthProvider.facebook.name())) .controlFlag(REQUIRED)
.options(socialOptions) .add() .add() .build();
But I found the PAM inspired REQUIRED/REQUISITE/SUFFICIENT/OPTIONAL stack
not entirely intuitive to work with in practice.
> 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).
Quite interesting, but especially those extra methods may make it difficult
for this JSR, unless we align our efforts with the Servlet spec perhaps?
(we have to align at some point anyway)
At any length, multiple authentication mechanisms in essentially a 2D grid,
combined with the other outstanding wish to have multiple identity stores
makes for quite a complex setup. I'd love to see if we can prepare anything
here, but there's only so much resources we have for this JSR.
It's likely at least a post EDR1 discussion.
Kind regards,
Arjan Tijms