...
Info |
---|
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. It is deeply imperfect, minimally supported, and should not be viewed as a security feature or treated as reliable. Trivial and recommended browser settings can render it totally non-functional. It has no future. You should understand all of that before even considering it. |
Table of Contents |
---|
Proprietary/Simple Logout
...
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.
...
By default, 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 idp.logout.promptUser property can be set to a Predicate bean that allows the user to make a cancel decision.
Configuration
The idp.session.trackSPSessions property must be enabled to support the SLO propagation feature (it is explicitly enabled by default for new installs but defaults to false).
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 idp.logout.elaboration property to 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:
...
CAS Registered Service Example
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" /> |
...
The UI in this version has a general model that presents the applicable subset of three options to the user:
Logout of the IdP only
Logout of the IdP and SPs where possible
Canceling the logout
The latter option can be enabled by setting the idp.logout.promptUser property to the name of a Predicate bean that evaluates to true under the desired conditions.
...
Finally, the design of the logout feature does not support returning control of the user agent to any other system via a "return" parameter or similar mechanism. While this remains officially unsupported, the idp.logout.preserveQuery 4.1 property can be set to true to cause any parameters on the original request to be preserved and made accessible via a ScratchContext object underneath the ProfileRequestContext. Note that any kind of redirection strategy that is not constrained in some way will turn the IdP into an Open Redirector.
...
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.
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 use of SOAP obviously requires server-side session state. Propagation to SPs via SOAP when possible is supported more or less automatically, and happens either as part of back-channel processing or as a result of the usual front-channel iframe-based propagation.
Basic Configuration
The idp.session.secondaryServiceIndex property must be enabled to support SAML logout requests (it is explicitly enabled by default for new installs, but defaults to false).
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.
Hide if | ||||
---|---|---|---|---|
| ||||
Advanced OptionsEven 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 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 A bean is also exposed in V4.2+ to allow message level encryption of |
Reference
Localtabgroup | ||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
The following may be defined in conf/global.xml if needed. |