Thanks for the feedback. I had also considered your second solution (re-broadcasting) but have debating whether I should keep it outside the CAS client or embed that logic in the CAS single signout filter.
Bryan Wooten [email protected] Work: 801.585.9323 Cell: 801.414.3593 From: Nathan Kopp [mailto:[email protected]] Sent: Friday, July 09, 2010 12:00 PM To: [email protected] Subject: RE: [cas-user] useSession=false problem As a general principal, each cluster should take care of its own clustering. If your CAS Server is clustered, it handles anything affected by the fact that you have more than one CAS Server (i.e. use a clustered version of your ticket caches). When a CAS client is clustered, then the client machines should manage any of their own cluster-specific logic. The server shouldn't care (because it is viewing the cluster as a single machine, which is what you want... the CAS Server is an external actor compared to the cluster and should view the cluster as a black box). We use a custom C++ ISAPI client and a customized version of the older 2.1.x Java CAS client. I've also played around with one of the clients in the 3.x range, but we're not using that in production currently. I've used two methods for a cluster-aware single sign-out CAS client: 1) If your user session state is already clustered (standard practice with Tomcat or most other Java app servers), you just make sure that the CAS Client's single log-out (SLO) code will result in the session being invalidated or cleared. Do this on one node and it will become true on all nodes by nature of the clustered session. We're not using the latest CAS Client, so I don't personally know how its SLO features work internally. 2) Configure each client in the cluster to re-broadcast the SLO command to the other nodes in the cluster. I've done this with another servlet filter that sits in front of the standard CAS servlet filter. All nodes are configured identically with the internal addresses for all nodes, and the one that receives the command just loops through the list (skipping over itself). An extra parameter (or something) should be included to tell the other node not to rebroadcast again, avoiding an endless loop. Another possibility, if all of your clients and server exist on a single domain, is to have the CAS server create a domain cookie that acts as a SLO command. (Using a domain cookie for login is less secure than the standard CAS protocol, but using it for logout shouldn't introduce any practical vulnerabilities.) I haven't actually implemented this mechanism, but I think it could work very effectively. -Nathan From: Bryan Wooten [mailto:[email protected]] Sent: Friday, July 09, 2010 12:39 PM To: [email protected] Subject: RE: [cas-user] useSession=false problem Nathan, Your assessment is 100% correct. We really do require single sign out. We have to assume that all our applications will be accessed from public terminals. We must do our best to protect our users from themselves. There is no real way to train 30,000 students... May I ask how you got single sign out to work in a load balanced environment and which client you used? From what I know about single sign out, making it work in a load balanced situation is a CAS server side problem and not a CAS client issue. Cheers, Bryan Wooten [email protected] Work: 801.585.9323 Cell: 801.414.3593 From: Nathan Kopp [mailto:[email protected]] Sent: Friday, July 09, 2010 9:56 AM To: [email protected] Subject: RE: [cas-user] useSession=false problem First, it is possible to use single logout behind a load balancer (we do it for a number of our critical applications), but it depends on the CAS client implementation. (Not all clients support single logout, and those that support it don't always work in a cluster.) It really seems that single logout is a requirement for your implementation, so I would pursue that route. Many implementations assume that the user is using a private machine or that users can be trained to shut down all browser windows (to ensure single logout) before allowing someone else to use the computer. If these are not true of your situation, you will want to enforce a policy that all CAS clients be configured to support single logout. In our environment, we use single logout for most critical applications, but we also rely on private workstations and users closing browser windows for other applications. It would probably not be a good idea to disable local application sessions completely. Applications would probably not behave as expected. You could implement a back-channel callback for CAS clients to re-check the state of the user's server session, but this would require custom code in both the client and server and it would probably severely impact system performance due to increased network traffic. There are other single logout strategies that could be used (e.g. use a domain cookie indicate session state to clients within the server's domain), but they all would require code changes to the CAS server and clients. -Nathan From: Bryan Wooten [mailto:[email protected]] Sent: Friday, July 09, 2010 11:23 AM To: [email protected] Subject: RE: [cas-user] useSession=false problem Ok, sorry if this gets a bit long winded. The behavior I will describe below is causing one of our developers to scream, "Security Holes!". So I am doing my best mitigate his concerns and along the way I am trying to gain a deep understanding of the ins and outs of the CAS Client and Server. So here is the scenario, 2 users and 2 applications, using a Firefox browser. I access application 1 as user 1 and get redirected to CAS login. After login I can use application 1. Now I browse to the CAS logout URL and it says I am successfully logged out. Except as we know, I am not really logged out of application 1 (single sign is disabled for all applications because we are behind a load balancer). So here is the first "Security Hole", the user can still access the application without being asked to log in again. Now if I try to access application 2, I will be asked to login in again. So I login as user 2 and use application 2. Now here is the second "Security Hole". In application 1 I am still known as user 1 and in application 2 I am know as user 2. The developer feels that the second login should mean that application 1 should now see me as user 2. I believe all this is explained by the behavior of JSESSION IDs since each application gets its own jsession (but I could be way off on this assessment) I have no clue what would happen if I introduced a 3rd application into the mix. If I hit the 3rd application which login would it recognize? I am trying to find a way to make my applications always go back to the CAS server to see if the user has logged out via the CAS logout URL. I don't know if this is even possible without custom code. I am open to writing my own custom filter or modifying the CAS client itself. I was hoping some combination of renew = true or useSession=false would accomplish this. I have tried various combination of renew=true and useSession=false and different filter ordering, none of which I can get to work. So at this point I am planning on diving head first into the client code and figure out exactly what the parameters do and how they work. I also recognize that our applications should all have "logout" buttons or links that would allow us to invalidate the session and log that application out of CAS. I won't bore you will the politics of the logout button. Sigh. Thanks, Bryan Wooten [email protected] Work: 801.585.9323 Cell: 801.414.3593 From: Scott Battaglia [mailto:[email protected]] Sent: Thursday, July 08, 2010 7:50 PM To: [email protected] Subject: Re: [cas-user] useSession=false problem What order do you have the filters in? Also, is there a reason you don't need sessions? On Thu, Jul 8, 2010 at 1:26 PM, Bryan Wooten <[email protected]<mailto:[email protected]>> wrote: When I set useSession=false in the Cas20ProxyReceivingTicketValidationFilter I get this after I : Firefox has detected that the server is redirecting the request for this address in a way that will never complete. If I set renew=true in conjunction with use=Session= false I can never get off the CAS login page. Any ideas? Thanks, Bryan Wooten [email protected]<mailto:[email protected]> Work: 801.585.9323 Cell: 801.414.3593 -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
