Hi,
On Tue, Jan 26, 2016 at 12:14 PM, Darran Lofthouse <
darran.lofthouse_at_redhat.com> wrote:
> After a rather hectic end to last year have finally managed to get back
> into reviewing mode ;-)
>
Great to see you back here ;)
once you move beyond simple username / password based authentication you
> quickly move into the realm of validating responses to challenges - or to
> put this another way there is no longer a credential exchanged that can be
> validated.
It's indeed not necessarily a case of providing a single credential to the
store and validate that. In that case the authentication mechanism plays a
(much) bigger role and the store a smaller one.
If I understand you correctly, it's a little what a friend on my has done
when building an OAuth/Social provider based SAM. See
https://github.com/omnifaces/omnisecurity-socialauth/blob/develop/src/main/java/org/omnifaces/security/socialauth/jaspic/authmodules/SocialServerAuthModule.java
It redirects the user to the OAuth provider (e.g. Facebook), then upon
being redirected back it validates the access token and exchanges it for a
grant by contacting Facebook itself (no store involved up to this point).
The store is not invoked until the authentication mechanism has in fact
decided the caller is authenticated. See
https://github.com/omnifaces/omnisecurity-socialauth/blob/develop/src/main/java/org/omnifaces/security/socialauth/jaspic/authmodules/SocialServerAuthModule.java#L258
What it does is then not actually validating (the mechanism has already
done that), but giving the application a chance to translate the ID the
caller has with the social provider (E.g. Johnie23) to the ID it has in the
application (e.g. john.smith) and provide the list of groups that caller
has within the application (which obviously the social provider can't
provide).
So the identity store still stores identities and groups, but they are
local to the application and no actual credential validation is being
performed. This particular store accepts the incoming caller ID and trusts
that authentication has been performed by the mechanism.
I hope I got it right and the above makes sense in this context.
In the previous JAAS based approaches all requests would result in a
> 'credential' being passed to a JAAS login module to authenticate - over
> time this ends up becoming quite a mess, items that are not credentials end
> up being wrapped as though they are, HTTP or SASL mechanisms specifics leak
> into your login module
Indeed, it's the equivalent to a DAO or business service using the
HttpServletRequest object to obtain parameters itself. Not so nice.
> The result of these experiences means that we have now found it necessary
> to move to an architecture where we consider the authentication mechanism
> having the responsibility to make the authentication decision.
Hasn't this really always been the case, at least theoretically? The
authentication mechanism can delegate the credential validation to the
identity store, but it's not absolutely required to do so.
Specifically the ServerAuthModule and by extension the proposed
HttpAuthenticationMechanism can make the decision completely internally, as
by the above example.
For the HttpAuthenticationMechanism see
https://github.com/arjantijms/mechanism-to-store-x/blob/master/jsr375/src/main/java/javax/security/authentication/mechanism/http/HttpAuthenticationMechanism.java
> So in general I think within WildFly Elytron we are going above and beyond
> the scope of this JSR
It seems like a very interesting and sensible direction. Surely something
to monitor and take into account for Java EE Security 2.0 JSR?
For this JSR the scope is quite limited ("low hanging fruit"), but we
should indeed be careful that we don't paint ourselves into a corner and
prevent more elaborate setups later.
Kind regards,
Arjan Tijms