How do I configure IdP or SP initiated Single Logout in Identity Cloud or AM (All versions)?

Last updated Jan 16, 2023

The purpose of this article is to provide information on configuring IdP or SP initiated Single Logout (SLO) in ForgeRock Identity Cloud or AM.

3 readers recommend this article

Background information

When a user signs into an IdP and multiple SPs using Single Sign On, the IdP keeps track of all the SPs that it has sent an authentication response to. When the user subsequently logs out from one SP, the IdP knows which other SPs they are logged in to and can send logout requests.

When SLO is initiated by the SP, the SP attempts to log out of the IdP that was the source of the assertion for the user's session.

With Standalone Mode, there are two JSP pages that you can include in the URL that you are calling when a user logs out to initiate SLO depending on whether IdP or SP initiated: idpSingleLogoutInit.jsp or spSingleLogoutInit.jsp respectively. For example:

The following URL would provide single logout initiated by the IdP: https://idp.example.com:8443/am/saml2/jsp/idpSingleLogoutInit.jsp?metaAlias=/idp&spEntityID=SP&binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
The following URL would provide single logout initiated by the SP: https://sp.example.com:8443/am/saml2/jsp/spSingleLogoutInit.jsp?metaAlias=/sp&idpEntityID=https%3A%2F%2Fidp.example.com%3A8443%2Fam

Optionally, you can call the jsp using IDPSloInit or SPSloinit under the context root instead. For example:

The following URL would provide single logout initiated by the IdP: https://idp.example.com:8443/am/IDPSloInit?binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
The following URL would provide single logout initiated by the SP: https://sp.example:8443/am/SPSloInit?metaAlias=/sp&idpEntityID=https%3A%2F%2Fidp.example.com%3A8443%2Fam

You can specify other parameters in the URL to control the resulting logout behavior using & to separate different parameters. See the Logout URL guidelines section below for further information to help you construct your URLs.

Note

It is the IdP's responsibility to decide where to send the logout requests; you can use the logoutAll parameter for an IdP initiated logout URL, which sends a logout request to all service providers (regardless of whether they have an active session or not) to override the IdP's decisions.

Logout URL guidelines

The following guidelines will help to ensure your logout URL functions as expected:

SP initiated logout URL

You must include idpEntityID and binding type in your URL unless you use HTTP-Redirect binding (HTTP-Redirect binding is the default binding used when binding is not specified).
metaAlias is optional when you specify idpEntityID although recommended.
idpEntityID is always required for fedlets.
idpEntityID should be URL encoded.

IdP initiated logout URL

You must include binding in your URL if using a binding type other than HTTP-Redirect (default).
metaAlias is optional when you specify spEntityID although recommended.

See JSP pages for SSO and SLO (Identity Cloud) or JSP pages for SSO and SLO (AM) for further information on these parameters.

Binding options

You can use one of the following binding values:

binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect, which uses the HTTP Redirect binding.

This binding is the default option and all communications between IdPs and SPs are through the browser using a URL query string, which means direct connections are not required; the IdP bounces the browser back and forth between each SP to achieve logout. The potential downside to this approach is if an IdP or SP fails to respond, some sessions may be left active and the user could end up stuck on an error page part way through the logout process. Additionally, HTTP-Redirect should be used for transmitting small messages (AuthnRequests, LogoutRequests, etc) SAML Responses tend to be quite large which can impact the URL length since they are transmitted as an HTTP query parameter (URLs over 2,000 characters will not work in most web browsers). For example, if you send a SAML assertion with HTTP redirect binding it will fail to deliver the whole response if you reach the limitation. As mentioned below, HTTP-POST binding is more suitable for long messages.

binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST, which uses the HTTP POST binding.

This binding is also commonly used and all communications between IdPs and SPs are through the browser using a self-submitting XHTML form; again direct connections are not required and the IdP bounces the browser back and forth between each SP to achieve logout, resulting in the same potential downside as the HTTP Redirect binding. HTTP-Post binding is suited for transmitting long messages (those containing signed or encrypted SAML assertions, such as SAML Responses etc.) as they are transmitted as part of the request body (as self-submitting XHTML form) not as part of the URL, and not subject to browser URL length limits.

binding=urn:oasis:names:tc:SAML:2.0:bindings:SOAP (IdP only), which uses the SOAP binding.

This binding sends direct communications on a back channel between IdPs and SPs (requiring direction connections), which overcomes the possibility of an IdP or SP failing to respond via the browser. However, message encoding is more complicated.

binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact (SP only), which uses the HTTP Artifact binding.

This binding uses the Artifact Resolution Protocol and the SOAP binding for its direct communications between IdPs and SPs; it is therefore similar to the SOAP binding but suitable for SP initiated logouts.

See How do I know which binding to use for SAML2 federation in Identity Cloud or AM (All versions)? for further information.

Caution

For the binding parameter, you must use the full long name, for example, urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST instead of HTTP-POST, otherwise you will get a HTTP-400 error (Requested binding is not supported).

Related Training

ForgeRock Access Management Deep Dive (AM-410)

Related Issue Tracker IDs

N/A