Instead of having CAS send a different principal back to Google, why not use Google's SAML reference implementation (http://code.google.com/apis/apps/sso/saml_reference_implementation.html), protect it with CAS and have Google's SAML code lookup up the correct principal for GoogleApps based on the principal that was passed from CAS?
It seems like it would be easier to modify and maintain Google's SAML tool than make the changes necessary to do this in CAS and maintain your changes in future versions. -Eric On Fri, Aug 1, 2008 at 11:27 AM, Scott Battaglia <[EMAIL PROTECTED]> wrote: > 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 > > -- Eric Pierce, RHCE -- University of South Florida -- (813) 974-8868 -- [EMAIL PROTECTED] _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
