>> 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.
Well in the end it's just a database table, let's say with ID,
username, password. It's a bit more complicated than that of course.
So given:
ID, username, password
1, jsmith, password1
2, jsmith, password2
3, jdoe, password3
And a UsernamePasswordCredential(jsmith, password1) I can construct a
SimplePrincipal(1, ...) etc. I was hoping that the fact that I already
figured out that this was record '1' in the AuthenticationHandler
could be used in the PrincipalResolver immediately. Instead I would
have to do the lookup again using the same logic *if* I want to
separate the authentication and the resolving of the principal is what
I hear your you say.
>> 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.
Right so basically you're saying it's simply not necessary to split
the resolving and authentication in that case. I can understand that,
however it seems I have a slightly different case. More on this below.
>> 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.
Again, seems fair however this is not (IMHO) what the contract
specifies. You are saying 'authenticated credential', but are
specifiying 'credential'. There is no way to sort of 'upgrade' an
unauthenticated credential to an 'authenticated credential' between
the authenticationhandler and the principalresolver. It assumes that
the principalresolver can do it's work given the same data
(credential) as the authentication handler.
What I was expecting to work (without having looked at the sourcecode
was the following) was that I could sort of enrich the principal that
is contained in the HandlerResult with data from the authentication
store that was then available in the PrincipalResolver. In short I was
assuming that the line:
principal = resolvePrincipal(handler.getName(), resolver, credential);
looked like:
principal = resolvePrincipal(handler.getName(), resolver,
handler.getCredential());
That way I could have specified in my authenticate something along the lines of:
---
return createHandlerResult(new MyAccountCredential(account.getId()),
new SimplePrincipal(...), emptyList());
---
And let the PrincipalResolver handle resolving based on MyAccountCredential.
>> 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?
Our. Not really really slow, but slow enough that I would like to not
repeat the process.
>
>> 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.
So what I'm saying is: I have disparate stores, but the principal
resolution store can't work given only the credential. It needs a bit
more info that I am already retrieving when I'm authenticating so
that's where my question arose from. I realise how I can fix this
(simply put it all in a single AuthenticationHandler and not configure
a PrincipalResolver) I was just curious whether or not I missed
something.
> 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
--
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
