I've considered that solution for re-broadcasting. The ideal situation would be if there's a lightweight library out there that can handle either multicast or unicast messaging via configuration (I'd rather not write one).
Otherwise, we can just hook into all of your JMS topics, right? ;-) On Fri, Jul 9, 2010 at 4:00 PM, Bryan Wooten <[email protected]> wrote: > 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]> > 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] > > Work: 801.585.9323 > > Cell: 801.414.3593 > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > -- > 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
