PingOne

SAML 2.0 single logout

PingOne supports SAML 2.0 single logout (SLO), which enables users to sign off from multiple participants in a single action. Participants are the identity provider (IdP) and the service provider (SP), and are referred to as partners of each other. SLO is most common in workforce deployments, in which employees can sign off from multiple applications in a single operation.

This section describes the benefits, behaviors, and limitations of SAML 2.0 SLO.

  • SAML applications and IdPs can trigger SLO only if:

    • An SLO endpoint is configured.

    • The user interacts with the application or IdP within the configured SLO window.

      Learn more about the SLO settings in Editing an application - SAML.

  • Signing off from a SAML application or IdP with the conditions described above doesn’t trigger PingOne to send logout requests to OpenID Connect (OIDC) or Microsoft 365 applications the user has signed on to in the same PingOne user session.

  • Signing off from an OIDC or Microsoft application doesn’t trigger SAML 2.0 SLO.

  • The default sign-off method for the PingOne application portal and PingOne Self-Service - MyAccount is OIDC logout. You can change the sign-off method to SAML 2.0 SLO as needed. Learn more in Configuring the application portal and Configuring the self-service portal.

SLO scenarios

You can use SAML 2.0 SLO in several different scenarios:

SP-initiated SLO

For SP-initiated SLO, PingOne is the IdP, and the partner is the SP with a SAML application in PingOne. If the partner supports SP-initiated SLO, an application can send logout requests to PingOne.

IdP-initiated SLO

For IdP-initiated SLO, the partner is the IdP, and PingOne is the SP with an external IdP connection to the partner. If the partner supports IdP-initiated SLO, the IdP can send logout requests to PingOne.

PingOne-initiated SLO

For PingOne-initiated SLO, if PingOne is the IdP, and if the SP supports IdP-initiated SLO, PingOne can send logout requests to the SP. If PingOne is the service SP, and the IdP supports SP-initiated SLO, PingOne can also send logout requests to the SP.

To start a PingOne-initiated SLO request, the browser sends an HTTP GET request to either of the following URLs:

  • https://auth.pingone.<region>/<envID>/saml20/startslo

  • https://<customDomain>/saml20/startslo (Only if a custom domain has been configured. Learn more in Setting up a custom domain.)

SLO traffic

SLO messages (requests and responses) are transported through the browser. PingOne supports two SLO bindings that define how messages are transported:

  • POST (default)

  • Redirect

SLO behavior

Generally speaking, when a participant initiates a SAML 2.0 SLO request, based on the user’s action, requests and responses are exchanged among all participating partners. The goal is to sign the user off from all partners.

When PingOne is a participant, and it receives an SLO request, if PingOne is aware of other participants, PingOne sends an SLO request to each participant in a sequence after each successful SLO response PingOne receives. When no participants remain, PingOne honors the original SLO request and returns a successful SLO response to the participant that originally sent the request.

When PingOne is the initiator, the SLO process works similarly. However, the SLO should finish with PingOne when it receives the last successful SLO response.

The chain succeeds when each participant completes its share of the SLO process. The chain breaks when one participant fails to complete the SLO request.

When SLO fails, the participant is supposed to return the browser to the initiator with an error message. If the participant is unable to do so, the participant would typically show a message directly to the user. In either case, the user can close the browser and optionally clear the browsing data, such as cache and cookies, to terminate sessions from all participants.

Applications and SLO

If the SP supports SLO, enter the SLO endpoint in the SAML application. This is the endpoint at the SP where it receives SLO requests. If the SP wants to receive SLO responses at a different endpoint, enter that as the SLO response endpoint. The SLO binding defaults to POST and also supports Redirect.

Because SLO can time out if one participant fails to send an SLO message, you can configure how long PingOne should send or receive SLO messages to and from an application since the initial request. This per-application flexibility allows you to fine-tune SLO experiences for your users.

External IdPs and SLO

SAML 2.0 external IdPs work the same way as SAML 2.0 applications. If the IdP supports SLO, enter the SLO endpoint in the external IdP configuration. This is the endpoint at the IdP where it receives SLO requests. If the IdP wants to receive SLO responses at a different endpoint, enter that as the SLO response endpoint. The SLO binding defaults to POST and also supports Redirect.

Because SLO can time out if one participant fails to send an SLO message, you can configure how long PingOne should send or receive SLO messages to and from a SAML 2.0 external IdP since the initial request. This per-external IdP flexibility allows you to fine-tune SLO experiences for your users.