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.

Protocol Support

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:

  1. Application logout - ends a single application session
  2. 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.

SSO Sessions

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.

CAS Logout

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:

The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.

The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This flag indicates that the presence of the setting is not immediately necessary in the end-user CAS configuration, because a default value is assigned or the activation of the feature is not conditionally controlled by the setting value.

  • cas.logout.confirm-logout=false
  • Before logout, allow the option to confirm on the web interface.

  • cas.logout.follow-service-redirects=false
  • Whether CAS should be allowed to redirect to an alternative location after logout.

  • cas.logout.redirect-parameter=service
  • 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 service.

  • cas.logout.redirect-url=
  • 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.

  • cas.logout.remove-descendant-tickets=false
  • 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.