LogoutConfiguration

File(s): conf/idp.properties, views/logout.vm, views/logout-complete.vm, views/logout-propagate.vm

Proprietary/Simple Logout

Functional Description

When an HTTP GET request is made to the /profile/Logout endpoint with a valid IdP session cookie, the corresponding IdP session is ended and the logout.vm view is rendered that informs the user of the following:

1. The IdP session is ended.
2. Lists all services accessed during the IdP session, if tracked, and offers to end those sessions by propagating a logout message to each one.

If the user chooses SLO, the logout-propagate.vm view is rendered and the browser mediates (i.e. front-channel) a series of logout messages coordinated via iframes, javascript, and in some cases HTML5 storage. The result is a best-effort attempt to explicitly end each relying party session by sending a protocol-specific message to each service endpoint. In the IdP configuration, the SLO messaging process is called propagation. The IdP attempts to display prominent status information on the result of each attempt to end a relying party session; a red X for failure or a green checkbox for success.

If the uses chooses to end without SLO, logout-complete.vm is rendered and a message is displayed indicating that some relying party sessions may still be active.

At present, the IdP session is terminated regardless of the user's choice. In other words, the question asked is "propagate or not?" rather than "logout or not?". The implications of this have been the subject of mailing list discussion and additional flexibility may be developed for future releases. You may also choose to copy and adapt the system-supplied logout flow locally to behave differently if you want to do that work.

Configuration Changes

The following property in idp.properties must be enabled to support the SLO propagation feature.

# Track information about SPs logged into
idp.session.trackSPSessions = true

If you want the displayed information about services to be customized by the use of SAML metadata (for things like service names and logos), you should also set the following property:

# Whether to lookup metadata, etc. for every SP involved in a logout
# for use by user interface logic; adds overhead so off by default.
idp.logout.elaboration = true

In order for CAS protocol services to participate in SLO, the singleLogoutParticipant attribute must be set to true in the service definitions that identify the service:

<bean class="net.shibboleth.idp.cas.service.ServiceDefinition"
      c:regex="https://([A-Za-z0-9_-]+\.)*example\.org(:\d+)?/.*"
      p:group="slo-services"
      p:authorizedToProxy="false"
      p:singleLogoutParticipant="true" />

UI Considerations

In most cases it should not be necessary to modify the logout view templates. Some deployers may choose to make SLO mandatory, which would require modifying logout.vm as follows:

#if ( $logoutContext and !$logoutContext.getSessionMap().isEmpty() )
    <meta http-equiv="refresh" content="0;url=$flowExecutionUrl&_eventId=propagate">
#end

The SLO machinery is a fairly complex interaction between embedded iframes and javascript that drives and processes logout messages. That logic, due to its implementation nature, is confined to a system view file, idp/system/views/logout/propagate.vm. Modification of that file is discouraged.

Browser Support

The SLO feature requires a fair bit of mature Javascript support, but any browser that supports HTML5 Local Storage should work. While the SLO implementation is based on modern Web standards, browser features vary so greatly that it's hard to identify minimum browser requirements. To underscore the point, we identified a problem caused by the inability of IE to recognize the application/json media type (IDP-879) in the SLO support that shipped in 3.2.0.

SAML Logout

TBD...but refer to the above material for most of the common considerations.