PingFederate Agentless SLO Sequence

Question

I goofed it up. Big time. My apologies.

I went and did some playing, and it works, very different. And we'll update our documentation, because it SHOULD be in there. In the short term, we're posting a KB article, but it hasn't wound through the approval workflows yet. So... In the mean time... Here's my massive edit.

SP Agentless Adapter Single Log-Out (SLO)

The SLO process on the SP side is similar to the IDP SLO process, however different attributes are returned during the pickup process and the user’s local application session will be destroyed rather than the authentication process session.

The below steps are for a front-channel SLO. In a back-channel scenario, PingFederate will call the logout page with any attributes you define in the querystring. You can then kill the session with the values passed from PingFederate.

For example, if the sessions were maintained in a database according to the subject of the assertion, to use back-channel logout, I can modify the PingFederate configuration to specify back-channel logout and set the logout service endpoint to include “?subject=${subject}” appended to the SLO url.

The application would then need to take this “subject” query parameter (as opposed to the “REF” parameter it receives in a front-channel SLO) and kill the appropriate application sessions.

SLO Process Initiation

During a front-channel SLO activity a request will be made to the “Logout Service Endpoint” defined in the IDP adapter configuration. This request will contain a “REF” parameter for the SLO endpoint to use to retrieve attributes about the session requesting logout.

HTTP Response
HTTP/1.1 302 Found
Headers
Content-Type:   text/html;charset=UTF-8
Location:   https://app.company.com/signout?REF=PPQQRRSSTTUUVVWWXXYYZZ11223344
Body
<N/A>

Step 1 – Grab the REF attribute

When an SLO request is received, this REF parameter must be retrieved and used to pickup attributes regarding the session requesting logout. The value will be referred to as [REF_VALUE] in the steps below and be populated with the value of “PPQQRRSSTTUUVVWWXXYYZZ11223344”.

Step 2 – Pickup the information about the Logout

Similar to an SSO request, the adapter will make a HTTP GET request to the pickup endpoint to retrieve attributes about the logout:

HTTP Request
GET https://pf.company.com:9031/ext/ref/pickup?REF=PPQQRRSSTTUUVVWWXXYYZZ11223344 HTTP/1.1
Headers
Authorization:  BASIC YXBwX3VzZXI6YXBwX3Bhc3N3b3Jk
ping.instanceId:    app
Body
<N/A>

The response will contain information about the session requesting logout.

HTTP Response
HTTP/1.1 200 OK
Headers
<N/A>
Body
{
"resumePath":"\/sp\/pCyCo\/resume\/sp\/SLO.ping",
"sessionid":"sFMcTOaropYv5gYQZi1ZOpX7DZ8"
}

The following attributes will be returned in the response:

Attribute - Description resumePath - URL to send the user at the end of the local logout process to continue the SLO activity.
sessionid - The sessionid PingFederate uses to track the authenticated session. This will be the same as the value received when the SSO attributes are picked up.

Step 3 – Destroy the local application session

The SLO page will parse these attributes and destroy the local session (ie delete session cookies) and perform any logout processing corresponding to the attributes. (ie if the session maintained a row in a database, the application could use the sessionid provided to delete these rows and end the session).

Also in the returned attributes is the resumePath value that is needed in the next step to redirect the user after destroying the session. This will be referred to as the [RESUME_PATH] value and will contain the value /sp/pCyCo/resume/sp/SLO.ping retrieved from the response above.

Step 4 – Return the user to PingFederate

To continue the SLO process, the user must be returned to the [RESUME_PATH] gathered in Step 3. The source of the resume request must also be provided on this URL and appended as a “source” query parameter. So using the following variables:

·[PINGFEDERATE_SERVER] value from configuration
·[RESUME_PATH] value gathered in Step 3
·[ADAPTER_INSTANCE_ID] value from configuration

Taking these three components we can create the full resume URL using the format:

[PINGFEDERATE_SERVER] + [RESUME_PATH] + ?source= + [ADAPTER_INSTANCE_ID]

Which results in a redirect of:

HTTP Response
HTTP/1.1 302 Found
Headers
Content-Type: text/html;charset=UTF-8
Location: https://pf.company.com:9031/sp/pCyCo/resume/sp/SLO.ping?source=app
Body
<N/A>

The local application logout process is now complete and the user will continue with the SLO activity.

Error Handling

Similar to the IDP scenario, any errors during the processing of pickup and dropoff requests from PingFederate will be returned as HTTP status codes. For example if an incorrect client ID or password was specified, then a 401 HTTP error would be returned during the pickup / dropoff process.

The application will only receive a sign-in request from a previously authenticated user. Any errors received during the authentication process should be handled as appropriate with application branding. The user would have already completed the authentication process at the IDP.

Note: Error screens should be located outside the protected content. When a user receives an error during the sign-in or authorization stages, they need to be able to view the error rather being sent back through the authentication process.

By the way... While SLO is certainly part of SAML... I think it's a mess - especially when you have BIG organizations (like SFDC and Google) that don't participate. I wrote a blog post on it.