> So when I got the point of 'enriching' the principal with some
> additional metadata I was surprised to see that that resolver got the
> same credentials as the authentication handler.
That's the contract: given an authenticated credential, determine a principal.
> I have to re-run the code that I have in my authentication handler
> again right?
Not necessarily. You'd have to say more about the details of the
queries you're executing and the back end data store(s).
> Due to the fact that the underlying data is rather
> polluted I can even have multiple accounts with the same email address
> where only the password differentiates
In the common CAS protocol case, only the principal ID is conveyed to
clients. How will clients distinguish between two users named "jsmith"
that map to different people? The metadata you mentioned? Note you
will have to release that metadata as attributes that the client can
consume to disambiguate. This is a vital concern that you must address
before you proceed.
> Relevant code in the AuthenticationManager:
> ---
> final HandlerResult result = handler.authenticate(credential);
> ...
> resolver = this.handlerResolverMap.get(handler);
> if (resolver == null) {
> principal = result.getPrincipal();
That assignment is new and supports principals resolved directly from
the authentication handler data store. In many cases, if not the
common case, the principal is just another attribute in the same
record as the username or other user primary ID. In that case you
would not configure a resolver and you would fall into this block.
> logger.debug(
> "No resolver configured for {}. Falling back to handler
> principal {}",
> handler.getName(),
> principal);
> } else {
> principal = resolvePrincipal(handler.getName(), resolver, credential);
This implements the PrincipalResolver contract: given the
authenticated credential, determine a principal.
> Basically I was expecting the second to last line to use
> 'result.getPrincipal()' instead of just 'credential'.
Hopefully my comments above shed some light.
>
> The lookup of the principal in the authenticationhandler is also
> rather slow :-|.
Due to your systems or our components?
> I see that if I don't set a resolver I can enrich the
> principal in the authentication handler myself and eventually that
> principle will be used, but it doesn't seem 'correct'.
That behavior is by design as I mentioned above. If you're querying
the same data store for the principal as that used to authenticate,
you may be able to simply enhance an out-of-box AuthenticationHandler
to suit your needs. Mixing PrincipalResolver and AuthenticationHandler
at this point is primarily to support disparate identity stores; for
example Kerberos for authentication and LDAP for principal resolution.
M
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
