...
| Info |
|---|
Single Logout (SLO) support is new in 3.2.0. SLO is a best-effort attempt to end relying party sessions without clearing the browser's cookie and storage state. Most browsers do not clear this state when closed. |
| Table of Contents |
|---|
Proprietary/Simple Logout
...
Overview
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:
...
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
...
The following property in idp.properties must be enabled to support the SLO propagation feature.
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<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. In order for SAML services to participate in SLO, the SAML metadata supplied for them must contain appropriate <SingleLogoutService> endpoints. In addition, SPs vary in how they handle security, and SLO is in general vastly less interoeprable than SSO in SAML, so you should not expect uniform results. Shibboleth itself assumes that all logout messages are signed, and if you need to interoperate with SPs that don't sign their logout responses, you will need to set the following property:
| Code Block | ||||
|---|---|---|---|---|
| ||||
# Whether to require logout requests/responses be signed/authenticated.
idp.logout.authenticated = false
|
UI Considerations
The look and feel of the logout process can be changed through modification of the view templates, message properties, etc.
Some deployers may choose to make SLO mandatory, which would require modifying modifying the <head> content of logout.vm as follows:
| Code Block | ||||
|---|---|---|---|---|
| ||||
#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 complex and fragile nature, is confined to a system view file, idp/system/views/logout/propagate.vm. Modification of that file is discouraged and will not survive upgrades.
Browser Support
The SLO feature requires a fair bit of mature Javascript support, but any browser that supports HTML5 Local Storage should workLocalStorage should work (this use of LocalStorage is independent of the choice of storage service, it applies even when server-side storage is used). 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 3V3.2.0.
SAML Logout
TBD...but refer to the above material for most of the common considerationsSAML Logout is a more complex protocol than the simple variant described above, but the implementation is shared across the two approaches. There are really two "halves" to this:
- Responding to requests from an SP
- Propagating logout to an SP
This section is about the first case. The propagation step is covered in the previous section and is the same, regardless of how the logout is initiated.
SPs can request a logout using either front- or back-channel SAML bindings (typically HTTP-Redirect on the front, SOAP on the back). The IdP supports reception of either type of request, but currently cannot propagate logout using SOAP (but if you rely on a server-side session storage option, it can terminate the session at the IdP).
Configuration
The following property in idp.properties must be enabled to support SAML logout requests:
| Code Block | ||||
|---|---|---|---|---|
| ||||
# Support lookup by SP for SAML logout
idp.session.secondaryServiceIndex = true |
| Note |
|---|
The default storage solution used for session is based on cookies and does not support the secondary indexing feature. You can either enable the use of HTML LocalStorage, which does support that feature, or switch to a server-side storage service option. See the StorageConfiguration topic for information on either of these approaches. Of course, using the client-side storage option does not allow for back-channel logout. |
Another consideration with SAML logout has to do with the length of time the system will "remember" the SP's session, in order to prevent the session cache from growing endlessly. This can't be done precisely because the IdP doesn't actually know how long the SP's own session might last. The idp.session.defaultSPlifetime and idp.session.slop properties control how long the IdP will "remember" an SP's session. Once elapsed, it's likely that a request for logout will fail from any SP that has expired from the cache.