> In the Single-sign-on(SSO) framework, CAS Server becomes the critical > component. Its failure will result in all applications not accessible. How > to overcome this?
There is no recipe for a highly available (HA) CAS solution. There are a number of considerations that you need to evaluate against your requirements, environment, and expertise to develop a solution. We really need to document this on the wiki, so I will provide a thoughtful discussion here which will hopefully form the basis of a wiki document in the near future. - Availability of back-end authentication stores and other dependent systems. There's no sense having a highly available CAS server if you have a single point of failure in the underlying authentication store. - Do you need scalability/redundancy across hosts, networks, facilities, or geographic locations? The cost and complexity increases from left to right in that list. - The choice of CAS components has an effect on system architectures to provide for availability. For example, choosing the default in-memory ticket registry prevents an active-active CAS setup. On the other hand, the default in-memory component is suitable for an active-passive setup where the passive node(s) are on hot standby. - What security/usability requirements come to bear on the solution. For example, some environments have a requirement that a node failure does not affect SSO session state. In that case, an active-passive setup where there is no state sharing between nodes (e.g. in-memory ticket storage) is not acceptable. Many deployers have described their setups; you can search the list archives for "HA", "available", "redundant", and other relevant keywords. I would imagine the Google Groups mirror [1] has the best search interface. M [1] https://groups.google.com/forum/?fromgroups#!forum/jasig-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
