Scott Battaglia wrote: > 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? Yes, and this should probably be extended to metadata populators. If I remember well, 3.0 authenticates in three stages: 1. users are authenticated by calling a chain of authenticators 2. credentials are resolved to a principal calling a chain of resolvers 3. metadata are populated thanks to a chain of populators IMHO, the problem is that there are cases where only the authenticator that succeeded in the authentication exactly knows how to resolve the credentials and populate the metadata. That's why I think the actual authentication manager should chain more complex objects, where each one should: 1. authenticate 2. resolve 3. populate Here is the way I see the ideal authentication manager. Sorry if not accurate, I did not work on CAS v3 since last summer. Best, PA
> > -Scott > > On 2/1/07, *Stephen A. Cochran* <[EMAIL PROTECTED] > <mailto:[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] <mailto:[email protected]> > http://tp.its.yale.edu/mailman/listinfo/cas > > > ------------------------------------------------------------------------ > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > -- http://perso.univ-rennes1.fr/pascal.aubry _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
