SP-initiated SSO—POST-POST

In this scenario a user attempts to access a protected resource directly on an SP web site without being logged on. The user does not have an account on the SP site, but does have a federated account managed by a third-party IdP. The SP sends an authentication request to the IdP. Both the request and the returned SAML assertion are sent through the user's browser via HTTP POST.

Figure 1: SP-Initiated SSO: POST/POST
Processing steps
  1. The user requests access to a protected SP resource. The request is redirected to the federation server to handle authentication.

  2. The federation server sends an HTML form back to the browser with a SAML request for authentication from the IdP. The HTML form is automatically posted to the IdP's SSO service.

  3. If the user is not already logged on to the IdP site or if re-authentication is required, the IdP asks for credentials (e.g., ID and password) and the user logs on.

  4. Additional information about the user may be retrieved from the user data store for inclusion in the SAML response. (These attributes are predetermined as part of the federation agreement between the IdP and the SP—see About attributes.)

  5. The IdP's SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP.

    NoteSAML specifications require that POST responses be digitally signed.
  6. (Not shown) If the signature and the assertion (or the JSON Web Token) are valid, the SP establishes a session for the user and redirects the browser to the target resource.

Tags Capability > User Provisioning; Capability > Single Sign On; Hosting Environment > On-Premises; Product > PingFederate > PingFederate 8.3; Product > PingFederate; Task Type > Deployment

Your Rating: