Thanks Marvin for your long answer. I agree with you about the necessity to get a unique NetID. We are joining 3 universities into a single one. So the only "almost" unique identity is supannaliaslogin for two of us and uid for my university. So if we answer differently upon tle login form, that should be correct. We already test the accounts and probability to get login+pass equality should lead to the same person registered in several universities. For historical reason, two universities joined before, keeping uid for login but sending a prefix for the netid. dupont is transformed in u1.dupont or u3.dupont depending on the ldap successfull bind. They add a javascript to do the trick, but I prefer to do all on the server side.
I'll look to your hints. Thks Dom 2010/12/21 Marvin Addison <[email protected]> > I encourage you to consider some potential problems with > authenticating against multiple user stores: > > - With the CAS protocol only the principal ID (NetID) is available to > uniquely identify a user. If you cannot guarantee global uniqueness > of principals across all user stores, there will be uncertainty among > CAS-enabled applications about which human person corresponds to a > particular principal. This has some significant negative security > implications. > > - If a human user has accounts in both user stores, you will likely > have some usability problems; for example, which credentials should > the user provide at the CAS login form? > > To your particular problem, you would likely need to subclass > UsernamePasswordCredentials to have an additional attribute that holds > a "source" value > > > So when we add several several credentialsToPrincipalResolvers in > > deployerConfigContext.xml, we only do a search but without the bind, > > we don't know which DN we will get. > > My question is: Is the a way to know which bind context has been > > used and so call the right credentialsToPrincipalResolvers. > > I would imagine you will need a custom AuthenticationManager for this > where you can perform the search on a context and immediately attempt > authentication on the same context if you get a search result. That > removes the uncertainty about which context produced the result. I > would recommend reviewing AuthenticationManagerImpl, and planning a > custom implementation to do what you need. It should be a > straightforward custom component to develop. > > Alternatively, if you want to put the directory to search under the > user's control, you could develop one or more subclasses of > UsernamePasswordCredentials that includes an additional attribute that > helps the AuthenticationManager find the correct context to search and > bind. The user would provide this information on the login form. I'm > picturing something similar to the Shib WAYF functionality where users > choose an institution to authenticate against. I believe you'd still > need a custom AuthenticationManager for this, but I imagine it would > be a one-off of DirectMappingAuthenticationManagerImpl. > > 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 > -- Dominique LALOT Ingénieur Systèmes et Réseaux http://annuaire.univmed.fr/showuser.php?uid=lalot -- 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
