> > 1) I have 2 authentication handlers that are used concurrently, one
> > which uses a DB query and the other a LDAP query...
> > Is this an appropriate use of the postAuthenticate method, or am I
> > twisting this extensibility point in a way it isn’t intended?
>
> Sounds like a creative use though I wouldn't call it wrong or twisted.
>
> The recommended way to do what you're doing is by leveraging the
> PrincipalResolver components. Resolvers naturally execute after
> authentication using the credential as input and produce a principal;
> in your case you would query AD using the objectGuid in the database
> record as a search filter. You can map a resolver to an authentication
> handler so that a particular one fires only after the desired handler
> succeeds. I can provide more guidance on configuration if you're
> interested in that approach.
>
> Again, there's nothing wrong with your approach per se, it just short
> circuits some of the natural authentication pipeline that could
> probably handle it with OOB components.
I tried to use a PrincipalResolver originally, but it seemed inefficient. The
AuthenticationHandler already does the LDAP query to get the ObjectGuid for the
user, but the PrincipalResolver only has access to the Credentials used by the
AuthenticationHandler initially. For the username, I allow users to use their
sAMAccountName or their email address:
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. Am I missing
something in my PrincipalResolver that would allow me to take advantage of the
work already done by the authentication handler?
Thanks.
--
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
