On Tue, Jan 26, 2016 at 2:41 PM, Darran Lofthouse <
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?
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>> 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
>>
>>