Brodie, Your best bet is to do this: 1. Install two CAS servers 2. Google Apps and any other app that needs the alternate ID should point to CASG (the random name I just made up for this) 3. All other apps should point to CAS (the "real" CAS).
CASG should be put in place such that all it does is delegate authentication to CAS (unfortunately the code that can do this, the Berkeley contribution is not yet publicly available [unless I'm remembering wrong]). Its easy enough to write yourself though. The best way to write your own is to protect the /login URL with the CAS Authentication and Validation filters and also the Request Wrapper filter. Then use the "Trusted" module to accept the username from the request object and in a custom CredentialsToPrincipalResolver you can look up the attribute based on the NetId provided and return the real Id that you want. There are some optimizations that can be done to make it more efficient, etc. but that's probably the quick and dirty way. -Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Thu, Jul 31, 2008 at 6:16 PM, Brodie Rao <[EMAIL PROTECTED]> wrote: > After working around this in the code, it seems principal IDs are > getting cached. When I log into one instance, the other instance returns > back the principal that was resolved from my original login. Is there > any way to work around this? > > Brodie Rao wrote: > > That's right. > > > > As I said in my original email I'd have two differently configured CAS > > instances sharing tickets. One would return mailNickname as the > > principal ID to CAS clients (for Google Apps), and the other would > > return username passed in (as it normally does). > > > > Scott Battaglia wrote: > >> I'm not sure what you're trying to do. Its set to the context path > >> explicitly. Are you deploying CAS under two different request context > >> paths? > >> > >> -Scott Battaglia > >> PGP Public Key Id: 0x383733AA > >> LinkedIn: http://www.linkedin.com/in/scottbattaglia > >> > >> > >> On Thu, Jul 31, 2008 at 4:24 PM, Brodie Rao <[EMAIL PROTECTED] > >> <mailto:[EMAIL PROTECTED]>> wrote: > >> > >> Actually, it looks like this is a behavior of > >> org.jasig.cas.web.flow.InitialFlowSetupAction. Is there any way to > >> disable or work around this behavior? > >> > >> Brodie Rao wrote: > >> > I'm trying out the clustering idea with 3.3-RC2 and memcached, > >> but I've > >> > run into one snag: the two servlets aren't sharing cookies. The > >> cookie > >> > path is being set to the servlet path, despite p:cookiePath being > >> set to > >> > "/" in TG and warn cookie generators. > >> > > >> > I have emptySessionPath set in Tomcat, so the JSESSIONID cookies > are > >> > being shared, just not CASTGC/WARN. Reading up on Tomcat it looks > >> like > >> > it prepends the servlet path by design. Is there any way to get > >> around this? > >> > > >> > Scott Battaglia wrote: > >> >> 3.3 shouldn't have any major configuration changes from 3.2 so > >> it should > >> >> be an easy upgrade. We're hoping to release 3.3 soon as "final" > >> I'm > >> >> just waiting to hear back if anyone has any problems since I > >> haven't had > >> >> time to do my own testing yet. > >> >> > >> >> -Scott > >> >> > >> >> -Scott Battaglia > >> >> PGP Public Key Id: 0x383733AA > >> >> LinkedIn: http://www.linkedin.com/in/scottbattaglia > >> >> > >> >> On Thu, Jul 24, 2008 at 8:40 PM, Lucas Rockwell < > [EMAIL PROTECTED] > >> <mailto:[EMAIL PROTECTED]> > >> >> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: > >> >> > >> >> Scott, > >> >> > >> >> Thanks! I will just try it with 3.3 if possible for what I > >> am doing. > >> >> > >> >> -lucas > >> >> > >> >> On Jul 24, 2008, at 5:15 PM, Scott Battaglia wrote: > >> >> > >> >>> I'm not sure I haven't tried it. 3.2 has an AtomicBoolean > >> in one > >> >>> of the Tickets which can't be used in Terracotta. 3.3 > changes > >> >>> that (hence the version switch). > >> >>> > >> >>> -Scott > >> >>> > >> >>> -Scott Battaglia > >> >>> PGP Public Key Id: 0x383733AA > >> >>> LinkedIn: http://www.linkedin.com/in/scottbattaglia > >> >>> > >> >>> On Thu, Jul 24, 2008 at 8:02 PM, Lucas Rockwell > >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > >> >>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: > >> >>> > >> >>> On Jul 16, 2008, at 6:56 PM, Scott Battaglia wrote: > >> >>> > > >> >>> > If that's not possible, is it possible to configure a > >> second > >> >>> > instance of > >> >>> > the CAS server mounted at a different URL that shares > the > >> >>> same ticket > >> >>> > store as the first server? That way I could point > Google > >> >>> Apps to that > >> >>> > second instance, and keep existing applications > >> pointed at > >> >>> the first > >> >>> > instance. > >> >>> > > >> >>> > CAS can share ticket stores. We've got a few options > >> including > >> >>> > JBossCache, MemCache, and Terracotta. The last two > >> will be > >> >>> as of 3.3. > >> >>> > >> >>> Does this means that if I were to try Terracotta with > >> CAS 3.2.x, I > >> >>> would be beating my head against the wall? > >> >>> > >> >>> -lucas > > _______________________________________________ > > 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 >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
