PingOne supports SAML 2.0 SLO, which enables users to sign out of multiple participants. Participants are the IDP (identity provider) and the SP (service provider), and are referred to as partners of each other. SLO is most common in workforce deployments, in which employees can log out of multiple applications in a single operation.
- Only SAML applications and identity providers that have SLO configured can trigger SLO.
- OIDC apps, including PingOne system apps like the PingOne Application Portal and PingOne Self-Service - MyAccount, cannot use SLO.
SLO scenarios
You can use SAML 2.0 SLO in several different ways. See the following for a description of the different scenarios.
- SP-initiated SLO
- For SP-initiated SLO, PingOne is the identity provider, and the partner is the service provider 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 identity provider, and PingOne is the service provider 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 identity
provider, and if the service provider supports IdP-initiated SLO,
PingOne can
send logout requests to the service provider. If PingOne is the service
provider, and the identity provider supports SP-initiated SLO, PingOne can also send
logout requests to the service provider. 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. See 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) and 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 out 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 of them, one at a time, as it receives successful SLO responses from each of them. 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, it 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 not able 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 service provider supports SLO, enter the SLO endpoint in the SAML application. This is the endpoint at the service provider where it receives SLO requests. If the service provider 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, administrators 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 administrators to fine-tune SLO experiences for their users.
External IDPs and SLO
SAML 2.0 external identity providers work the same way. 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, administrators 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 administrators to fine-tune SLO experiences for their users.