For the concurrent HTTP authentication mechanisms I think the most
pressing issue is support for using mechanisms such as CLIENT_CERT,
SPNEGO and username/password (Either Digest, Basic, or FORM) concurrently.
Unless the API covers this up front this is one of the cases you can't
retrospectively refit - and as I say in my original mail, the only way I
have found to effectively achieve this is to split out the request and
response handling so a decision can be made outside the mechanism as to
if the response from that mechanism should even be sent.
On 26/01/16 13:10, arjan tijms wrote:
> Hi,
>
> On Tue, Jan 26, 2016 at 12:16 PM, Darran Lofthouse
> <darran.lofthouse_at_redhat.com <mailto: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
> <http://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
> <http://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
>