Follow

SAML 2.0 Profiles explained - Building your own SAML integrations

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: 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)
  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.
    Note: SAML 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.

 

SP-Initiated SSO--Redirect-POST

In this scenario, the SP sends an HTTP redirect message to the IdP containing an authentication request. The IdP returns a SAML response with an assertion to the SP via HTTP POST.

Figure: SP-Initiated SSO: Redirect/POST


Processing Steps:
  1. A user requests access to a protected SP resource. The user is not logged on to the site. The request is redirected to the federation server to handle authentication.
  2. The SP returns an HTTP redirect (code 302 or 303) containing a SAML request for authentication through the user’s browser 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)
  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.
    Note: SAML 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.

 

SP-Initiated SSO--Artifact-POST

In this scenario, the SP sends a SAML artifact to the IdP via an HTTP redirect. The IdP uses the artifact to obtain an authentication request from the SP's SAML artifact resolution service. The IdP returns a SAML response to the SP via HTTP POST.

Figure: SP-Initiated SSO: Artifact/POST


Processing Steps:
  1. A user requests access to a protected SP resource. The user is not logged on to the site. The request is redirected to the federation server to handle authentication.
  2. The SP generates an authentication request and creates an artifact. The SP sends an HTTP redirect containing the artifact through the user’s browser to the IdP’s SSO service.
    Note: The artifact contains the source ID of the SP’s artifact resolution service and a reference to the authentication.
  3. The SSO service extracts a source ID from the SAML artifact and sends a SAML artifact-resolve message over SOAP containing the artifact to the SP's Artifact Resolution Service (ARS).
    Note: The SP and IdP’s source IDs and remote artifact resolution services are mapped according to the federation agreement made prior to this action.
  4. The SP’s ARS returns a SAML message containing the previously generated authentication request.
  5. 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.
  6. 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)
  7. 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.
    Note: SAML specifications require that POST responses be digitally signed.
  8. (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.

 

SP-Initiated SSO--POST-Artifact

In this scenario, the SP sends an authentication request to the IdP via HTTP POST. The returned SAML assertion is redirected through the user’s browser. The response contains a SAML artifact .

Figure: SP-Initiated SSO: POST/Artifact


Processing Steps:
  1. A user requests access to a protected SP resource. The user is not logged on to the site. 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)
  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 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 a valid assertion is received, a session is established on the SP and the browser is redirected to the target resource.

 

SP-Initiated SSO--Redirect-Artifact

In this scenario, the SP sends an HTTP redirect message to the IdP containing a request for authentication. The IdP returns an artifact via HTTP redirect. The SP uses the artifact to obtain the SAML response.

Figure: 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 is redirected to the federation server to handle authentication.
  2. The SP returns an HTTP redirect (code 302 or 303) containing a SAML request for authentication through the user’s browser 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)
  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 a valid assertion is received, the SP establishes a session and redirects the browser to the target resource.

 

SP-Initiated SSO--Artifact-Artifact

In this scenario, the SP sends a SAML to the IdP via an HTTP redirect. The IdP uses the artifact to obtain an authentication request from the SP. Then the IdP sends another artifact to the SP, which the SP uses to obtain the SAML response.

Figure: SP-Initiated SSO: Artifact/Artifact


Processing Steps:
  1. A user requests access to a protected SP resource. The user is not logged on to the site. The request is redirected to the federation server to handle authentication.
  2. The ACS generates an authentication request and creates an artifact. It sends an HTTP redirect containing the artifact through the user’s browser to the IdP’s SSO service.
    Note: The artifact contains the source ID of the SP’s artifact resolution service and a reference to the authentication request.
  3. The SSO service extracts the source ID from the SAML artifact and sends a SAML artifact resolve message containing the artifact to the SP's artifact resolution service.
    Note: The SP and IdP’s source IDs and remote artifact resolution services are mapped according to the federation agreement prior to this action.
  4. The SP’s artifact resolution service sends back a SAML artifact response message containing the previously generated authentication request.
  5. 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.
  6. 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).
  7. 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).
  8. 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).
  9. The ARS sends a SAML artifact response message containing the previously generated assertion.
  10. (Not shown) If a valid assertion is received, the SP establishes a session and redirects the browser to the target resource.

 

IdP-Initiated SSO--POST

In this scenario, a user is logged on to the IdP and attempts to access a resource on a remote SP server. The SAML assertion is transported to the SP via HTTP POST.

Figure: IdP-Initiated SSO: POST


Processing Steps:
  1. A user has logged on to the IdP.

    (If a user has not yet logged on for some reason, he or she is challenged to do so at step 2).

  2. The user clicks a link or otherwise requests access to a protected SP resource.
  3. Optionally, the IdP retrieves attributes from the user data store.
  4. 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.
    Note: SAML specifications require that POST responses be digitally signed.
  5. (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.

 

IdP-Initiated SSO--Artifact

In this scenario, the IdP sends a SAML artifact to the SP via an HTTP redirect. The SP uses the artifact to obtain the associated SAML response from the IdP.

Figure: IdP-Initiated SSO: Artifact


Processing Steps:
  1. A user has logged on to the IdP.

    (If a user has not yet logged on for some reason, he or she is challenged to do so at step 2).

  2. The user clicks a link or otherwise requests access to a protected SP resource.
  3. Optionally, the IdP retrieves attributes from the user data store.
  4. 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).
  5. 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).
  6. The ARS sends a SAML artifact response message containing the previously generated assertion.
  7. (Not shown) If a valid assertion is received, the SP establishes a session and redirects the browser to the target resource.

 

Questions?

If you have any questions or need some help, we would be happy to assist. Open a case at help.scorpionsoft.com or send an email to support@scorpionsoft.com.

 

 

 

 

 

 

 

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk