Hi, I'm sorry. That part about the hostname wasn't really clear. I was referring to the name appended to the tickets.
For instance: TGT-1-bS0yrHX0oJcY7aEv99ZyyDcfWdzeqF0o3VQi5cFHQc6KrUpYBc-someHost.someDomain I assume that needs to be the same so that either server will work with the ticket. I was planning to use session replication for a couple of reasons. 1. The clustering document in the CASUM<https://wiki.jasig.org/display/CASUM/Clustering+CAS> says to use it and 2. If we use session affinity, I can see an issue arising with the following scenario. If this is not how it would work, please correct me. I'm still new to all this. 1. User goes to service URL and is redirected through the load balancer to CAS-A. 2. User logs in and is granted a TGT from CAS-A. 3. The user is redirected back to the service, which attempts to validate the ticket. The load balancer directs the service's traffic to CAS-B 4. CAS-B didn't issue the TGT so it wouldn't validate and issue a ST. In that scenario, there is no way to ensure that the user and the service are going to communicate with the same CAS server. Given this hurdle, I didn't think session affinity was appropriate. I have not yet had a chance to test this yet, but I suspect that if the TGT has another server's name on it, that CAS will not process the ST request. If it will process that TGT from another server, given that they will share a ticket registry do I even need to do any form of replication/affinity at all? I can see one issue with that scenario. Assuming that the CAS server doesn't care about who made the ticket and I don't need any session replication, there's the possibility that the ticket registry may not be completely updated before the request from the service arrives at CAS-B. Since CAS-B didn't see the TGT, it would assume that there isn't one and direct them to log in again. Am I off base on this? I thought I had a decent grasp of what's going on, but like I said, I'm still new to all this. Geoff From: Jérôme LELEU [mailto:[email protected]] Sent: Thursday, August 1, 2013 3:48 AM To: [email protected] Subject: Re: [cas-user] Clustering/HA with MSSQL Backend Hi, This is not exactly what I meant. For the login process, you need to reuse the same web session (to validate the login ticket which is stored in session). In that purpose, you can replicate/share your web session between your CAS servers or use session affinity. I would recommend the second method which is really better for scalability... I'm not sure to understand : CAS application configured with the same name to enable the servers to work on the other's tickets ? Best regards, Jérôme 2013/7/31 Whittaker, Geoffrey <[email protected]<mailto:[email protected]>> Thanks for your response. I was curious if the tomcat sessions would replicate using ssl. I guess from your response that they do not and I'll need to configure that separately. I am running it on windows servers, and can just use IPSec if I need to. I thought that session affinity wouldn't work because the balancer would have no way of recognizing which server created the TGT when a service contacted it. The configuration I was planning on is to have two CAS servers: - Behind a load balancer, either in active/passive or active/active (haven't decided) - Using the same clustered SQL server as their ticket stores - Using Tomcat session replication secured via IPSec or some other method - CAS application configured with the same name to enable the servers to work on the other's tickets Does this sound like a workable plan or am I missing something? Geoff From: Jérôme LELEU [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, July 31, 2013 8:16 AM To: [email protected]<mailto:[email protected]> Subject: Re: [cas-user] Clustering/HA with MSSQL Backend Hi, You're right, if your datastore is already resilient, you just need to integrate your second CAS server with your datastore. That said, you need session affinity during the login process : the server which sends the login page must be the same which will receive the credentials filled in the login form. Otherwise, the authentication will fail. About security, the communication between your CAS servers and your datastore must be secure as the TGTs and STs associated with the user identities will be conveyed between both systems. For example, the network traffic between your CAS servers and your datastore should never go through internet. Both systems should be in the same DMZ or secured network. This is something you need to talk about with your ops team. Best regards, Jérôme 2013/7/31 Whittaker, Geoffrey <[email protected]<mailto:[email protected]>> I have recently managed to get my test CAS server to use our MSSQL server for the JPA ticket registry backend using the instructions found here: https://wiki.jasig.org/display/CASUM/JpaTicketRegistry and here: https://lists.wisc.edu/read/archive?id=13452694 and some tweaks that I learned along the way. I have read through https://wiki.jasig.org/display/CASUM/Clustering+CAS and I have a couple of questions. Since we have a clustered SQL setup, I shouldn't need to replicate tickets between two data stores as our SQL infrastructure is already fault tolerant. Given, that it seems the only thing I'd need to do at this point is configure my other test server to work with the same data store and then configure Tomcat session replication. Is that correct or am I missing something? Are there any security issues I need watch out for such as unencrypted traffic between the servers? Any help would be much appreciated. Thanks, Geoff -- 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]<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]<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]<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
