This example describes an SP-initiated SSO exchange. In such an exchange, the user attempts to access a resource on the SP, sp.example.com. However they do not have a current logon session on this site and their federated identity is managed by their IdP, idp.example.org. They are sent to the IdP to log on and the IdP provides a SAML web SSO assertion for the user's federated identity back to the SP.

For this example, the POST Binding is used to deliver the SAML <AuthnRequest>
message to the IdP and the Artifact Binding is used to return the SAML <Response> message containing the assertion to the SP.

NB: When using the HTTP Artifact binding for the SAML <Response> message, SAML permits the artifact to be delivered via the browser using either an HTTP POST or HTTP Redirect response (not to be confused with the SAML HTTP POST and Redirect Bindings). In this example, the artifact is delivered using an HTTP redirect.

Once the SP is in possession of the artifact, it contacts the IdP's Artifact Resolution Service using the synchronous SOAP binding to obtain the SAML message that corresponds to the artifact.

1. The user attempts to access a resource on sp.example.com. The user does not have a valid logon session (i.e. security context) on this site. The SP saves the requested resource URL in local state information that can be saved across the web SSO exchange.
2. The SP sends an HTML form back to the browser in the HTTP response (HTTP status 200). The HTML FORM contains a SAML <AuthnRequest> message encoded as the value of a hidden form control named SAMLRequest.
   
   <form method="post" action="https://idp.example.org/SAML2/SSO/POST" ...>
   <input type="hidden" name="SAMLRequest" value="request" />
   <input type="hidden" name="RelayState" value="token" />...
   <input type="submit" value="Submit" />
   </form>
   
   The RelayState token is an opaque reference to state information maintained at the service provider. (The RelayState mechanism can leak details of the user's activities at the SP to the IdP and so the SP should take care in its implementation to protect the user's privacy.)

   The value of the SAMLRequest parameter is the base64 encoding of the following <samlp:AuthnRequest> element:

   <samlp:AuthnRequest
   xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
   ID="identifier_1"
   Version="2.0"
   IssueInstant="2004-12-05T09:21:59Z"
   AssertionConsumerServiceIndex="1">
   <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
   <samlp:NameIDPolicy AllowCreate="true"
   Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
   </samlp:AuthnRequest>
   
   

3. For ease-of-use purposes, the HTML FORM typically will be accompanied by script code that will automatically post the form to the destination site (which is the IdP in this case). The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the identity provider's Single Sign-On Service.
   
   
   POST /SAML2/SSO/POST HTTP/1.1
   Host: idp.example.org
   Content-Type: application/x-www-form-urlencoded
   Content-Length: nnn
   SAMLRequest=request&RelayState=token
4. The Single Sign-On Service determines whether the user has an existing logon security context at the identity provider that meets the default or requested authentication policy requirements. If not, the IdP interacts with the browser to challenge the user to provide valid credentials.
5. The user provides valid credentials and a local logon security context is created for the user at the IdP.
6. The IdP Single Sign-On Service issues a SAML assertion representing the user's logon security context and places the assertion within a SAML message. Since in this example, the HTTP Artifact binding will be used to deliver the SAML Response message, it is not mandated that the assertion be digitally signed. The IdP creates an artifact containing the source ID for the idp.example.org site and a reference to the message (the MessageHandle). The artifact is delivered to the SP through a browser redirect.
7. The SP's Assertion Consumer Service now sends a SAML message containing the artifact to the IdP's Artifact Resolution Service endpoint. This exchange is performed using a synchronous SOAP message exchange.
   
   <samlp:ArtifactResolve xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
   ID="identifier_2"
   Version="2.0"
   IssueInstant="2004-12-05T09:22:04Z"
   Destination="https://idp.example.org/SAML2/ArtifactResolution">
   <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
   <!-- an ArtifactResolve message SHOULD be signed -->
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
   <samlp:Artifact>artifact</samlp:Artifact>
   </samlp:ArtifactResolve>
8. The IdP's Artifact Resolution Service extracts the MessageHandle from the artifact and locates the original SAML <Response> message associated with it. This <Response> is then placed inside a SAML <ArtifactResponse> message, which is returned to the SP over the SOAP channel.
   
   <samlp:ArtifactResponse
   xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
   ID="identifier_3"
   InResponseTo="identifier_2"
   Version="2.0"
   IssueInstant="2004-12-05T09:22:05Z">
   <!-- an ArtifactResponse message SHOULD be signed -->
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
   <samlp:Status>
   <samlp:StatusCode
   Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
   </samlp:Status>
   <samlp:Response>
   .....
   </samlp:Response>
   </samlp:ArtifactResponse>
   
   The SP extracts and processes the message and then processes the embedded assertion in order to create a local logon security context for the user at the SP. Once this is completed, the SP retrieves the local state information indicated by the RelayState data to recall the originally-requested resource URL. It then sends an HTTP redirect response to the browser directing it to access the originally requested resource.
9. The SP makes an access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.