I've created an issue covering this proposal here:
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-37
On Wed, Jan 27, 2016 at 11:12 AM, Werner Keil <werner.keil_at_gmail.com> wrote:
> 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
>>
>>
>>
>>
>
>