CAS 3.1 is designed to support single sign out. Whenever a Ticket Granting Ticket is explicitly expired, the logout protocol will be initiated. Clients that do not support the logout protocol may notice extra requests in their access logs that appear not to do anything.
Where Single Sign Out Works:
Where Single Sign Out "Doesn't Work" :
How it works:
When a CAS session ends, it will callback to each of the services that are registered with the system and send a POST request with the following:
The URL that will be POSTed to is the original service url.
At this moment the session identifier is the same as the CAS Service Ticket (the service ticket should be sufficiently long to be secure). The session identifier should map back to a session which can be terminated (i.e. deleted from a database, expired, etc.)
Alternative future choices for this protocol would be to transfer the LogoutRequest via SOAP (like SAML 1.1 responses).
Disabling Single Sign Out on the Server
Because not all clients support single sign out, you may need to disable it at the server level.
CAS server version 4.0.x
Since this version, the property slo.callbacks.disabled exists for the LogoutManagerImpl class (instead of the CasArgumentExtractor class) :
CAS server version 3.5.x
In that version, a property defines whether the Single Sign Out is disabled : slo.callbacks.disabled.
CAS server version <= 3.4.x
Each ArgumentExtractor has a property called "disableSingleSignOut", which if set to true will make sure the callback does not occur. To set it to true (i.e. turn off the "single sign-off" callback) edit your argumentExtractorsConfiguration.xml file as follows:
Disabling Single Sign Out on Ticket Registry Cleaner
CAS default behavior is to issue single sign out callbacks in response to a /cas/logout request or when a TGT is expired via expiration policy when a TicketRegistryCleaner runs. If you are using ticket registry cleaner, and you want to enable the single sign out callback only when CAS receives a request to /cas/logout you can configure your TicketRegistryCleaner like so:
Also note that some ticket registries don't use or need a registry cleaner, such as the Memcahed and Ehcache ticket registries. If you so decide to implement EhCache, the option of having a ticker registry cleaner is entirely done away with and is currently not implemented. With that being absent, you will no longer receive automatic SLO callbacks upon TGT expiration. As such, the only thing that would reach back to the should then be the /logout command issued to CAS.
Distributed vs non-distributed ticket registry behavior
Default in-memory ticket registry with a cleaner:
1. Suppose that logUserOutOfServices is set to true
Please note that simply removing a ticket by itself from the registry does not issue the SLO callback. A ticket needs to be explicitly told one way or another, to “expire” itself.
The logic of that is described below:
Distributed ticket registry, such as EhCache, no cleaner:
Please note that the behavior described from 2 to 4 in this case is standard case behavior for the /logout endpoint and executes regardless of the ticket registry type.