Adam,
Great! I am glad to hear your solution didn't modify any of the core code, which is always a concern, and took the higher road in handling it! =D 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: Wednesday, April 02, 2008 12:49 PM To: Yale CAS mailing list Subject: Re: Second-level CAS implementation Andy, Great questions! Let me try to answer them one at a time. If users logout from the less secure CAS server, are they made to log out of the more secure CAS server? Primary CAS has the SSOut turned on, and a filter on Second-level CAS catches and processes SSOut messages. It's a custom filter that finds a mapping from the original Primary CAS ST to the Second-level CAS TGT, and it invalidates its own TGT. So, yes, Primary CAS logout invalidates Second-level CAS SSO. What about logging out from the more secure CAS server; does it cause the user to logout of the less secure CAS server? No, that was not a requirement. 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. That's exactly how UC Berkeley wanted this to behave. 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. Well, when the Second-level CAS receives the SSOut message from Primary CAS, it doesn't have access to the TGT that is associated with the ST in the SSOut message. That's why custom code was required to map between them. Once the mapping finds the TGT to invalidate, it passes it to the destroyTicketGrantingTicket() method of the (unmodified) CentralAuthenticationService. There is also an event handler that listens to TicketEvents and manages the ST-to-TGT mappings. Adam Andrew R Feller wrote: 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
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
