PingFederate Server

SP-initiated SSO—Redirect-Artifact

In this scenario, the service provider (SP) sends an HTTP redirect message to the identity provider (IdP) containing a request for authentication. The IdP returns an artifact through HTTP redirect, and the SP uses the artifact to obtain the SAML response.

Diagram illustrating the SP-initiated SSO redirect-artifact process between the browser interface, the SP, and the IdP.
SP-initiated SSO—Redirect-Artifact

Processing steps

  1. A user requests access to a protected SP resource. The user is not logged on to the site. The request redirects to the federation server to handle authentication.

  2. The SP returns an HTTP redirect, either code 302 or 303, containing a SAML request for authentication through the user’s browser to the IdP’s single sign-on (SSO) service.

  3. If the user is not already logged on to the IdP site or needs to re-authenticate, the IdP asks for credentials, such as ID and password, and the user logs on.

  4. The user data store can provide additional information about the user for inclusion in the SAML response. The federation agreement between the IdP and the SP predetermines these attributes. See User attributes.

  5. The IdP federation server generates an assertion, creates an artifact, and sends an HTTP redirect containing the artifact through the browser to the SP’s Assertion Consumer Service (ACS).

  6. The ACS extracts the Source ID from the SAML artifact and sends an artifact-resolve message to the identity federation server’s Artifact Resolution Service (ARS).

  7. The ARS sends a SAML artifact response message containing the previously-generated assertion.

  8. (Not shown) If the IdP returns a valid SAML assertion to the SP, a session is established on the SP and the browser is redirected to the target resource.