> I tried to use a PrincipalResolver originally, but it seemed inefficient.
Not the first time someone has made that argument.
> ldap.authn.searchFilter=(|(sAMAccountName={user})(proxyAddresses=smtp:{user}))
>
> so I can't make too many assumptions based on their credentials. This means
> I would have to effectively redo the same search just done by the
> AuthenticationHandler to get the ObjectGuid that it already had.
Inefficiencies of this sort drove the creation of principal resolution
support directly in the AuthenticationHandler in CAS 4. At present
it's an either-or proposition: if the AH produces a principal, the
AuthenticationManager skips principal resolution in whatever
PrincipalResolver is configured for that handler. Your use case makes
me think we should support some configuration that makes that behavior
optional in order to support chaining resolvers, which I can admit is
a potentially powerful facility.
> Am I missing something in my PrincipalResolver that would allow me to take
> advantage of the work already done by the authentication handler?
Only if we do some further work to allow resolver chaining. That would
mean tweaking the contract of PrincipalResolver to accept either a
Credential or a Principal, but that sounds reasonable at first glance.
In any case I'm open to considering further in the context of an
enhancement targeting 4.1. Please file a Jira issue if that sounds
good to you. Thanks for sharing your use case.
M
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
