On 26/01/16 12:37, arjan tijms wrote:
> Hi,
>
> On Tue, Jan 26, 2016 at 12:14 PM, Darran Lofthouse
> <darran.lofthouse_at_redhat.com <mailto: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.
In this case the kind of mechanism I am thinking about is if a developer
wanted to use a mechanism such as HTTP Digest or HTTP SCRAM with this
identity store API - what I don't currently see is how a mechanism could
be implemented that works with this API without a lot of the mechanism
specific details leaking into the identity store implementation.
The problem with this is that the store then is no longer just about how
to access the backing store.
> 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 case of OAuth I agree, we are currently implementing a similar
flow within Elytron - in terms of API that token is wrapped in an
Evidence object and passed into our security realm to validate.
> 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.
What I am trying to say is the mechanism should also be able to pull the
information it needs out of the identity store so that it can use it for
validation.
> 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.
As a bare minimum I think we should verify the known existing HTTP
authentication mechanisms can be covered.
I agree about the low hanging fruit - I will have a look and see if I
can propose something to evolve it slightly. As I say from our own
research over the last year we have identifies the need ourselves for at
least one form of verify - it is just the case that this is not quite
sufficient for all scenarios.
> Kind regards,
> Arjan Tijms
>