On Sun, Sep 18, 2016 at 8:41 PM, Rudy De Busscher <rdebusscher_at_gmail.com>
wrote:
>
> I was just looking at the actual looping algorithm again here, but wasn't
>> it the idea that we would try all identity stores until one succeeds?
>>
>
>
> And if the first one that succeeds does only authentication, and not
> authorization? We don't have any groups then.
>
No that's not the case, it can return the groups at that point.
The first one that succeeds returns a CredentialValidationResult with a
CallerPrincipal and optionally one or more groups.
As mentioned above, the "loop over stores until valid" is probably the
> more common and expected approach, and additionally will also prevent this
> rather major issue.
>
> But then authorization and authentication can't be separated. Something
> which we do al the time.
>
It can absolutely still be separated. An identity store is free to not
return any groups if it's in the authentication list, while stores
configured for the authorisation list obviously only do authorization.
In the most common case with 1 identity store, the two operations are
combined. In many cases this is the most efficient way (i.e. only one query
to the backend needed).
If there are 2 identity stores, 1 can be used for authentication and if
that succeeds the other can be used to retrieve the groups from. Hence the
two operations are separated. See the algorithm sketch I provided a little
bit below. First all stores that can do authentication are consulted, after
that, optionally, all stores that only provide the groups are consulted.
(btw, taking terminology into account you could say that what we call
"authorization" is not actually authorization here. The list of groups is
just part of the authenticated identity. True authorization happens when
the caller actually attempts to access a resource and the authorization
module checks the permissions needed for that against the groups/roles that
the user is in)
Kind regards,
Arjan Tijms