IdP functionality

The following figure displays an example SSO process flow between PingFederate and the IdP application using the ReferenceID Adapter. The figure illustrates an SP-initiated scenario, but IdP-initiated SSO would be similar and processing could be optimized.

Processing Steps

  1. PingFederate receives an authentication request for a SAML assertion.
  2. The PingFederate server redirects the browser to the IdP application for authentication, including the resume path as a query parameter. The server needs the resume path back from the application to continue SSO processing after the user authenticates.
  3. The IdP application authenticates the user (if not already authenticated).
    NoteThe IdP applications must authenticate to PingFederate using one of three mechanisms. If authentication fails, the HTTP request results in an HTTP response 401 – Unauthorized status code message. See Authenticating to PingFederate.
  4. The IdP application uses a direct HTTP call to send the user attributes (as JSON-encoded objects) to PingFederate.

    For example:

  5. PingFederate stores the attributes and returns a reference in the HTTP response to the IdP application. See Reference value.
  6. The IdP application redirects the browser to the PingFederate resume path (received in Step 2) with the reference in the query string. For example:[resume-path]?REF=>
    NoteFor IdP-initiated SSO, an optimized flow is possible where steps 1 and 2 above do not apply. In step 6, the IdP application includes the reference (from step 5) as a query parameter when sending the user to the PingFederate SSO endpoint. For example:<startSSO parameters>&REF=<refid>
  7. (Not shown) PingFederate creates a SAML assertion using the attributes associated with the ReferenceID and sends the assertion to the Service Provider.

Tags Capability > Single Sign On; Hosting Environment > On-Premises; Product > Adapters and Integration Kits; Product > Adapters and Integration Kits > Integration Kits