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:

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.

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. You should only include this field in your
configuration if you need to modify the default value.}

cas.logout.confirm-logout=false

Before logout, allow the option to confirm on the web interface.

org.apereo.cas.configuration.model.core.logout.LogoutProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value. The only possible exception to this rule is when naming actuator endpoints; The name of the actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.logout.confirm-logout=...

This is the most common form of property configuration that is recognized by CAS, regardless of the actual property source, which might in fact be managed separately outside the CAS environment, by another system or cloud framework.

CAS properties can be specified using the YAML syntax:

cas: 
  logout: 
    confirm-logout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.logout.confirm-logout="..." -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory. Note the placement of the system property which must be specified before the CAS web application is launched.

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_LOGOUT_CONFIRM_LOGOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.logout.confirm-logout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

cas.logout.follow-service-redirects=false

Whether CAS should be allowed to redirect to an alternative location after logout.

org.apereo.cas.configuration.model.core.logout.LogoutProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.logout.follow-service-redirects=...

CAS properties can be specified using the YAML syntax:

cas: 
  logout: 
    follow-service-redirects: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.logout.follow-service-redirects="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_LOGOUT_FOLLOW_SERVICE_REDIRECTS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.logout.follow-service-redirects="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

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.

org.apereo.cas.configuration.model.core.logout.LogoutProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.logout.redirect-parameter=service

CAS properties can be specified using the YAML syntax:

cas: 
  logout: 
    redirect-parameter: "service"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.logout.redirect-parameter="service" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_LOGOUT_REDIRECT_PARAMETER="service"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.logout.redirect-parameter="service"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

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.

org.apereo.cas.configuration.model.core.logout.LogoutProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.logout.redirect-url=...

CAS properties can be specified using the YAML syntax:

cas: 
  logout: 
    redirect-url: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.logout.redirect-url="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_LOGOUT_REDIRECT_URL="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.logout.redirect-url="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

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.

org.apereo.cas.configuration.model.core.logout.LogoutProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

:information_source: Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

cas.logout.remove-descendant-tickets=...

CAS properties can be specified using the YAML syntax:

cas: 
  logout: 
    remove-descendant-tickets: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dcas.logout.remove-descendant-tickets="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export CAS_LOGOUT_REMOVE_DESCENDANT_TICKETS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --cas.logout.remove-descendant-tickets="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.