On 26/01/16 19:09, arjan tijms wrote:
> On Tue, Jan 26, 2016 at 2:41 PM, Darran Lofthouse
> <darran.lofthouse_at_redhat.com <mailto:darran.lofthouse_at_redhat.com>> wrote:
>
> 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.
>
>
> Do you mean that when called in an arbitrary order, two or more
> mechanisms indicate that they can handle the authentication for a given
> request, and then the caller ("handler") of those mechanisms makes a
> decision which one is actually used?
No what I mean is all mechanisms in a defined list are given an
opportunity to authenticate the incoming request - if one succeeds then
our mechanism is selected and that one will have provided the
authenticated identity.
If none succeed each mechanism is given an opportunity to add a
challenge to the response on the way back and the response is sent to
the client.
If one indicates that the authentication is in progress that mechanism
is given an opportunity to add it's response and the response goes back
to the client.
The main point being all mechanisms need to be given an opportunity to
authenticate the incoming request up until a success / in progress - it
is only at that point that the strategy for second responses /
challenges can be decided.
> Or that one mechanism actually handles the authentication, while an
> other starts sending an error (like the expired nonce message)?
>
> While potentially wasteful, what about passing in a wrapped response and
> extending the status codes returned by the validateRequest method?
>
> The current status codes seem to map a little already:
>
> SUCCESS -> authenticationComplete
> SEND_FAILURE -> authenticationFailed
> SEND_CONTINUE -> authenticationInProgress
>
> In the current draft proposal I just used the JASPIC AuthStatus, but it
> might be better to be a little more flexible here and use a JSR 375
> status type (which can be mapped to those from JASPIC).
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
> 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>
> <mailto: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>
> <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>
> <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
>
>
--
Darran Lofthouse - Principal Software Engineer
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Michael O'Neill(Ireland), Paul
Argiry (US)