Hi, Thanks for the response. That's good solid information and I appreciate it. Up to date docs are one thing, a friendly accurate, and responsive mailing list is even better!
- Aaron From: Jérôme LELEU [mailto:[email protected]] Sent: Tuesday, August 06, 2013 5:13 AM To: [email protected] Subject: Re: [cas-user] fault-tolerant/redundant/HA CAS deployment Hi, For those who complain about the "poor" documentation, I advice you to search accross the mailing lists. We already had several discussions about Ehcache/Memcached security/performance concerns. That said, I'm still to blame for not writing any documentation about that. Web sessions : I'm always against sessions replication : it doesn't scale well as you need to communicate between servers to share sessions or with a centralized third-party storage. The best architecture is always the "share nothing" one. So I would recommend to use session affinity at the load balancer level. And true, this is just for the login process. Tickets storage : EhCache is a simple and good solution. It is just a matter of configuration in your CAS server. You could even store tickets on disk for reliability (even if I don't think that the disk storage performs well). That said, EhCache with RMI is not very performant and is network bandwith consumer (mostly) because of the Java serialization. It works in most case so generally, it's the best solution. Memcached requires a little more mork at the beginning as you need to start some Memcached processes. Memcached is more performant than EhCache globally, but what really makes the difference is the serialization through the Kryo library (instead of the Java serialization). It's out of the box in the CAS server and for high traffic, I recommend it. About security, the easy solution is to rely on a secured network (your own internal infrastructure for example). Otherwise, no mechanism is provided by default with the CAS server to secure your data communication, you need to do that on your own. Best regards, Jérôme 2013/8/6 Pierce, Eric <[email protected]<mailto:[email protected]>> ________________________________________ From: Paul B. Henson Sent: Monday, August 05, 2013 8:14 PM To: [email protected]<mailto:[email protected]> Subject: Re: [cas-user] fault-tolerant/redundant/HA CAS deployment <snip> Once I get that working, I'm probably also going to try and cluster the underlying tomcat sessions. While a load balancer with sticky session support can work around not replicating that data, if you drop a server all of the people with sessions on that one will have to re-authenticate on the other one. Depending on your requirements that might be fine, but I'd rather avoid it. -- The tomcat session is only used during the initial authentication - it's just there to keep track of where the user is in the webflow during login. Once a user has authenticated and the TGT has been sent, the tomcat session isn't needed. If you lose a server, anyone who is in the process of logging in will see the login screen again, but as long as the ticket registry is replicated, anyone who has a CAS session will be fine. If you decide to use memcached for ticket replication and want to replicate Tomcat sessions, you may want to check out memcached-session-manager (https://code.google.com/p/memcached-session-manager) I haven't used it in production yet, but it's testing well with a few grails applications I'm working with. -- Eric Pierce Identity Management Architect Information Technology University of South Florida (813) 974-8868 -- [email protected]<mailto:[email protected]> -- 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
