SHIBBOLETH ------------------------------------------------------------------------ --- If you are interested in Shibboleth, pre-2.0 Shibboleth relies upon you to provide your own SSO, so you can use CAS for it. In Shibboleth 2.0, it is suppose to include a SSO so you wouldn't need a third-party product like CAS. In actuality, the Shibboleth paradigm isn't too different from CAS in that there is a identity manager (IdP) and some client code that protects an application (SP). The neat part about it is that you lay out contracts for attribute release, which is great if you want to do true federation.
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 an application to masquerade as the users who visit it. Typically, the CASTGC should be scoped for a (sub)domain that only the CAS servers have access to. CASTGC to NETID ------------------------------------------------------------------------ --- CAS uses the CASTGC to validate whether the user is logged in or not. If you look at the CAS protocols (http://www.ja-sig.org/products/cas/overview/protocol/index.html), the username is only available from validating a service ticket or proxy ticket from a CAS protected application. When the ticket is being validated, the application server doesn't know about the CASTGC nor does the user provide it to the CAS server; it must determine it from the ticket presented for validation. 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Brooks Sent: Wednesday, March 26, 2008 2:29 PM To: [email protected] Subject: Hacking CAS to get simple federated SSO Well, I'm heading back into some SSO work here and thought I would drop a note. Just a reminder, here is what I'm dealing with: 1. I have several CAS servers, each with their own CAS clients and user databases. 2. Each CAS server shares one group of users (e.g. they all have the same netids), and then had extra users on top of that that are not shared (and shouldn't be) 3. I want my applications to sit behind a CAS client that checks to see if the user is logged into any other cas server right now and, if so, to get their netid, see if it is in the shared list, and go on (if it's not in a shared list the user will just be given my login screen). The other CAS clients will probably not do the same (which is ok). It looks like shibboleth or something similar is what I really should be using, but this seems to heavy weight. Instead, I'm thinking of patching the CAS server code to add my CAS client url to the list of urls that the client will send cookies too. Thus when they hit my URL they'll get the CASTGC cookie and some indication of what server that cookie is from. My questions are: 1. How do I turn the CASTGC into a username without wrecking things? 2. Any pointers in the code? 3. Any obvious security issues with this? Best 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 _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
