...
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:
The IdP session is ended.
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.
...
SAML 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.
...
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.
...
| special | @anonymous |
|---|---|
| group | confluence-users |
Advanced Options
Even SPs that support requesting logout may not support receiving them, and many SPs may not care about responses to their requests. In such cases, it is advantageous to simple remove the <md:SingleLogoutService> endpoints from their metadata. Unfortunately this fails due to the IdP's requirement to try and issue a response in most cases, and results in an error.
A new option has been added in V4.2+, a property named idp.logout.assumeAsync, to allow requests to be treated as though they carried the <aslo:Asynchronous> extension element, which tells the IdP that no response is needed. This allows the removal of endpoints from SP metadata to be an effective means of mitigating such problems with SPs by allowing inbound logout to the IdP while preventing outbound logout.
A bean is also exposed in V4.2+ to allow message level encryption of <NameID> values to be suppressed based on Format. This is primarily suported to improve efficiency, given that many SPs rely on the urn:oasis:names:tc:SAML:2.0:nameid-format:transient format, which isn't all that important to encrypt. A typical bean definition in conf/global.xml:
| Code Block |
|---|
<util:set id="shibboleth.PlaintextNameIDFormats">
<util:constant static-field="org.opensaml.saml.saml2.core.NameIDType.ENTITY" />
<util:constant static-field="org.opensaml.saml.saml2.core.NameIDType.TRANSIENT" />
</util:set |
Administrative Logout 4.3
V4.3 adds a long-requested capability to log out sessions administratively. Right now this capability is confined to the IdP session (and that’s all that will ever be practical) and is implemented by means of revoking the authentication state of a subject. See AdministrativeLogoutConfiguration.
...