Agorava (based on PicketLink in the current version, what I see of Elytron,
it could also use it instead;-) uses CDI annotations instead of a limited
enum to resolve different types of social authenticators:
https://github.com/agorava/agorava-core
used by
https://github.com/agorava/agorava-twitter/
or
https://github.com/agorava/agorava-github
etc.
Kind Regards,
Werner
On Tue, Jan 26, 2016 at 2:10 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>
>
>
>