You are viewing the development documentation for the Apereo CAS server. The functionality presented here is not officially released yet. This is a work in progress and will be continually updated as development moves forward. You are most encouraged to test the changes presented.To view the documentation for a specific Apereo CAS server release, please choose an appropriate version. The release schedule is available here.
Logout and Single Logout (SLO)
There are potentially many active application sessions during a CAS single sign-on session, and the distinction between logout and single logout is based on the number of sessions that are ended upon a logout operation.
Note that SLO described here specifically deals with the semantics of the CAS protocol. All other available protocols in CAS may offer and behave differently when it comes to handling, receiving and publishing logout requests whether CAS is acting as an identity provider or service provider. SLO support for each protocol implementation may vary and you should always verify the extent of available functionality for each protocol implementation.
The scope of logout is determined by where the action takes place:
- Application logout - ends a single application session
- CAS logout - ends the CAS SSO session
Note that the logout action in each case has no effect on the other in the simple case. Ending an application session does not end the CAS session and ending the CAS session does not affect application sessions. This is a common cause of confusion for new users and deployers of an SSO system.
The single logout support in CAS attempts to reconcile the disparity between CAS logout and application logout. When CAS is configured for SLO, it attempts to send logout messages to every application that requested authentication to CAS during the SSO session. While this is a best-effort process, in many cases it works well and provides a consistent user experience by creating symmetry between login and logout.
It is possible to review the current collection of active SSO sessions, and determine if CAS itself maintains an active SSO session. See this page.
Per the CAS Protocol, the
/logout endpoint is responsible for destroying the current SSO session.
Upon logout, it may also be desirable to redirect back to a service. This is controlled via specifying the redirect
link via the
service parameter. The specified
service must be registered in the service registry of CAS and enabled and
CAS must be allowed to follow service redirects.
The following settings and properties are available from the CAS configuration catalog:
Before logout, allow the option to confirm on the web interface.
Whether CAS should be allowed to redirect to an alternative location after logout.
The target destination to which CAS should redirect after logout is indicated and extracted by a parameter name of your choosing here. If none specified, the default will be used as
A url to which CAS must immediately redirect after all logout operations have completed. Typically useful in scenarios where CAS is acting as a proxy and needs to redirect to an external identity provider's logout endpoint in order to remove a session, etc.
Indicates whether tickets issued and linked to a ticket-granting ticket should also be removed as part of logout. There are a number of tickets issued by CAS whose expiration policy is usually by default bound to the SSO expiration policy and the active TGT, yet such tickets may be allowed to live beyond the normal lifetime of a CAS SSO session with options to be renewed. Examples include OAuth's access tokens, etc. Set this option to true if you want all linked tickets to be removed.