Adam,
How does your logout policy work with this multi-level CAS setup? If users logout from the less secure CAS server, are they made to log out of the more secure CAS server? What about logging out from the more secure CAS server; does it cause the user to logout of the less secure CAS server? I imagine users logging out of the more secure CAS server would still be able to use the less secure CAS server and logging out of the less secure CAS server would log them off of the more secure CAS server. If this is the case, then the only custom coding someone else would need is to log the user out of both systems. The low road approach for this seems to be forwarding the user to the logout servlet of the secure CAS server while the high road would be a filter that recognizes the service ticket issued in the logout request and forces the invalidation of the user's ticket granting ticket. The problem with this second approach is that CAS wants to user to request a logout and doesn't have any accessible methods of externally invalidating a ticket granting ticket. Once again, I'm glad to hear how someone else is doing advanced work with CAS! Andy Andrew R Feller, Analyst University Information Systems 200 Fred Frey Building Louisiana State University <http://www.lsu.edu/> Baton Rouge, LA, 70803 (225) 578-3737 (Office) (225) 578-6400 (Fax) ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Rybicki Sent: Tuesday, April 01, 2008 7:27 PM To: Yale CAS mailing list Subject: Second-level CAS implementation While working with the University of California, Berkeley (UCB), Unicon implemented what UCB refers to as "Second-level CAS." The idea is that this server controls authentication to "highly secure" or "restricted" Web applications. These applications are CAS-enabled and use the Second-level CAS for their authentication. However, Second-level CAS is itself CAS-enabled, and in order to get to it, the user must first authenticate to the Primary CAS server. Obviously, Second-level CAS uses different type of credential (alphanumeric PIN one-way-hash-encoded and stored in LDAP) than Primary CAS (Kerberos). Additionally, Second-level CAS accepts and processes Single Sign-Out callbacks from Primary CAS and invalidates its TGT that was associated with the ST represented by the Primary CAS ST. So, this is pretty neat and UCB wishes to share this solution with the JA-SIG community. Before this gets packaged into some "contrib" package, I would like to document this solution on the JA-SIG Confluence. Can someone suggest the most appropriate place for this documentation? Thanks, Adam
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
