Every CAS deployer must answer the following question at some point in time, "What should happen if CAS goes down?" The reason this question is so important is because CAS is the gatekeeper deciding whether your constituents should use your web applications. Every CAS deployer starts off with the default settings for the lay of the land, but if you are concerned with user experience and service uptime, you will need to decide how far you want to go to ensure these important requirements. We will spend some time discussing the most common decisions made to this question, their benefits, and the costs associated with each.
Ticket Registry Strategies
CAS stores information about users in a ticket registry that keeps track of when users logged in, their usernames, the services they have logged into, how long their sessions are good for, etc. The ticket registry is one of the pieces that affects CAS service availability as we will see shortly.
Option 1: Standalone ticket registry
By default, CAS is configured to use an in-memory ticket registry that is constructed every time the server is started. This allows first-time deployers to quickly get an instance of the CAS server up and running with little effort at the cost of users' SSO information being erased if the server goes down. Some say this is an acceptable loss for several reasons:
If we were talking solely about whether users are required to login again in order to use a new application, then the default ticket registry might be enough. However, CAS server 3.1.1 and higher uses a feature called Single Sign Out (SSOut) that relies upon users' SSO information to expire users' application session whenever they go to logout of CAS. This has important implications whenever users leave their browsers open after logging out thinking that someone cannot use their protected applications. This issue is mitigated through the use of distributed ticket registries and elimintated through the use of persistent ticket registries.
Option 2: Distributed ticket registry
Distributed ticket registries reduce the risk of losing users' SSO information by storing it on multiple CAS servers. This effort lessens the possibilty of losing users' SSO information as a CAS cluster can recover as long as a single machine is up, however this does not completely eliminate the possibility. This provides a handful of additional benefits over the default ticket registry:
Though there are some benefits over the default ticket registry, there are also some drawbacks to this approach:
The following distributed ticket registries are available depending on the version of CAS you are deploying:
Option 3:Persistent ticket registry
Persistent ticket registries eliminate the risk of losing users' SSO information by storing it into an external datastore that can survive crashes. This is the high road in term of ticket registries as it buys very attractive benefits over both the default and distributed ticket registries:
Though there are a considerable number of benefits from this approach, there are also some drawbacks:
The following persistent ticket registries are available depending on the version of CAS you are deploying:
Every CAS deployer should spend some time reviewing the options availble for ticket registries in reference to their organizational needs and resources available to support the costs.