In an IdP-initiated use case, the identity provider is configured with specialized links that refer to the desired service providers. These links actually refer to the local IdP's Single Sign-On Service and pass parameters to the service identifying the remote SP. So instead of visiting the SP directly, the user accesses the IdP site and clicks on one of the links to
gain access to the remote SP. This triggers the creation of a SAML assertion that, in this example, will be transported to the service provider using the HTTP POST binding.

1. If the user does not have a valid local security context at the IdP, at some point the user will be challenged to supply their credentials to the IdP site, idp.example.org.
2. The user provides valid credentials and a local logon security context is created for the user at the IdP.
3. The user selects a menu option or link on the IdP to request access to an SP web site, sp.example.com. This causes the IdP's Single Sign-On Service to be called.
4. The Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed before it is placed within a SAML <Response> message. The <Response> message is then placed within an HTML FORM as a hidden form control named SAMLResponse. If the convention for identifying a specific application resource at the SP is supported at the IdP and SP, the resource URL at the SP can be encoded into the form using a hidden form control named RelayState. The Single Sign-On Service sends the HTML form back to the browser in the HTTP response. For ease-of-use purposes, the HTML FORM typically will contain script code that will automatically post the form to the destination site.
   
   <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
   <input type="hidden" name="SAMLResponse" value="response" />
   <input type="hidden" name="RelayState" value="token" />
   ...
   <input type="submit" value="Submit" />
   </form>
   
   The value of the SAMLResponse parameter is the base64 encoding of a <samlp:Response> element

    

5. 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 SP's Assertion Consumer Service.
   
   POST /SAML2/SSO/POST HTTP/1.1
   Host: sp.example.com
   Content-Type: application/x-www-form-urlencoded
   Content-Length: nnn
   SAMLResponse=response&RelayState=token
   
   The service provider's Assertion Consumer Service obtains the <Response> message from the HTML FORM for processing. The digital signature on the SAML assertion must first be validated and then the assertion contents are processed in order to create a local logon security context for the user at the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the desired application resource URL and sends an HTTP redirect response to the browser directing it to access the requested resource
6. 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.