Chris, Let me see if I can rephrase some of this:
SECURITY CONCERN ------------------------------------------------------------------------ - You don't want ANYTHING other than the CAS server to have access to this cookie: not the CAS client, the applications the client protects, etc. CAS clients run on the same application servers as the applications do, so if the CAS clients have access to it, then the applications themselves would have access to it. CREATION OF CASTGC ------------------------------------------------------------------------ - The CAS client doesn't create the CASTGC; the CAS server creates it whenever users login. The CAS client strictly protects an application by requiring unauthenticated users to provide it with a service ticket, which it will validate with the CAS server, and allowing those previously authenticated into the application. The CASTGC is used strictly by the CAS server in remembering whether or not you have previously logged in. It is most important whenever you are redirected to the CAS server after visiting an application protected by a CAS client for the first time. Since you have a valid CASTGC, the CAS server doesn't make you login again and it sends you back to the CAS protected application with the service ticket it needs. I will send you a diagram of the interaction within the CAS login experience in hopes it will illuminate what is going on. Andrew R Feller, Analyst University Information Systems 200 Fred Frey Building Louisiana State University Baton Rouge, LA, 70803 (225) 578-3737 (Office) (225) 578-6400 (Fax) -----Original Message----- From: Christopher Brooks [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 12:16 PM To: [email protected] Cc: Andrew R Feller Subject: Hacking CAS to get simple federated SSO Hi, Thanks for the reply. >SECURITY CONCERN >-------------------------------------------------------------------- >As for your questions, I would abstain from having the CASTGC available >to any of your application servers. This allows someone who compromises Right, actually, I was only going to have the CASTGC available to the other CAS clients. So my apps would be behind my CAS client, which would be able to get the cookies (CASTGC's) created by other cas clients out there. >CASTGC to NETID >---------------------------------------------------------------------- >CAS uses the CASTGC to validate whether the user is logged in or not. Ok, this is good to know. So if I share the CASTGC from cas client a to cas client b by way of a cookie (TCG), cas client b at least knows that this person is logged in. The docs say that a TGC contains a string that identifies a ticket granting ticket, but the TGT isn't really mentioned anywhere else, so I'm not sure of its importance. On one of our CAS 2 apps, I log in, then punch in a different URL that is protected with that same CAS client. There is no service ticket that I can see being passed (either as a cookie or as a URL parameter). Instead, all our filter gets is a couple of cookies (a sessionid and the castgc). If I get rid of the sessionid it still logs me in, so the filter must be using the castgc to let me into the app? So.... Can I take a CASTGC and validate it's authenticity by opening up a request to the CAS client who provided the cookie, then have it redirect me to a service that contains the username of the individual? Thus my second CAS server can validate both that they have been logged in as well as what their netid is? Assuming this works, can anyone suggest in the code where: 1. I should change the cookie params to be more lenient (e.g. to allow my second CAS client to be added as a host that the ticket should be given too) 2. A manner of getting the netid from a service ticket (which I should get when I am redirected after I present the TGC). Regards, Chris -- Christopher Brooks PhD Student, ARIES Laboratory Email: [EMAIL PROTECTED] Web: http://www.cs.usask.ca/~cab938 Mail: Christopher Brooks, MSc Department of Computer Science 110 Science Place Saskatoon, SK S7N 5C9 _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
