Would your DartmouthUserPassCred2PrincipalResolver be able to return a principal for the types of users that the new CredentialsToPrincipalResolver would be able to handle? If it doesn't recognize those users and would return null, then the chain would continue until it found one that did not return null.
I am looking at creating a more optimized algorithm (an alternative AuthenticationManager) that would allow you to specify a one-to-one mapping of authentication handlers and CredentialsToPrincipalResolvers. We do it the way we do now as it covers both scenarios where people have the mapping (its just less efficient) and people don't have the mapping. Thoughts? -Scott On 2/1/07, Stephen A. Cochran <[EMAIL PROTECTED]> wrote:
I'm adding our first sql based authentication handler to our test server, and it's raising a question in my mind. Currently we have three ldap auth handlers configured, and one DartmouthUserPassCred2PrincipalResolver that works for all of them. This new auth handler also creates UsernamePasswordCredentials, but it requires a different Cred2PrincipalResolver. The comments in the deployerConfigContext state that the resolvers will be tried in order until one that can handle the specific type of credentials presented. That to me sounds like the SQL resolver will never be used since the standard Dartmouth one that is set up for the LDAP auth handlers would match first. Am I understanding this correctly? And if so what's the solution? I'm guessing that I would have to create a new class, something like SQLUsernamePasswordCredientials, so that the standard LDAP resolver wouldn't match as a handling those credentials, and it would then look down the chain. Steve _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
