Federation Security Services Guide › Federation Security Services Overview › Federation Security Services Process Flow › Flow Diagram for SSO Using SAML 2.0 Authentication with Artifact Binding

Flow Diagram for SSO Using SAML 2.0 Authentication with Artifact Binding

The illustration that follows shows the detailed flow between a user's browser and the Federation Security Service components deployed at the Identity Provider and Service Provider. This set-up enables single sign-on between the sites and uses the SAML 2.0 authentication scheme with artifact binding as the authentication method.

The flow diagram assumes the following:

• The SP initiates the request for a resource.
• Successful authentication and authorization at the IdP and SP sites.

Note: This flow applies to examples that do not use the SAML Affiliate Agent.

The flow diagram for SAML 2.0 Authentication-Artifact Binding follows.

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the SiteMinder Federation Web Services application functions. In the flow diagram, the Web Agent block would be the embedded Web Agent in the SPS federation gateway. For information about installing and configuring the SPS federation gateway, see the CA SiteMinder Secure Proxy Server Administration Guide.

The sequence of events is as follows:

1. The user chooses a link at the SP to authenticate at a specific IdP. This link must include a Provider ID representing the chosen IdP.
2. SP FWS requests the IdP configuration information from the local Policy Server.
3. The local Policy Server returns the IdP configuration information to SP FWS. FWS may cache the configuration information.
4. SP FWS requests an AuthnRequest message from the local Policy Server via a tunnel call, passing the Provider ID. This call must contain the artifact profile in the ProtocolBinding element value.
5. The local Policy Server generates the AuthnRequest message in an HTTP redirect binding.
6. The local Policy Server returns the AuthnRequest message to the SP FWS in an HTTP redirect binding.
7. SP FWS redirects the user to the IdP SSO Service URL, which is obtained from the configuration information with the AuthnRequest message in an HTTP redirect binding.
8. The browser requests the IdP single sign-on service (SSO) URL.
9. IdP FWS requests the SP configuration information from the IdP local Policy Server.
10. The local Policy Server returns the configuration information. Note that FWS may cache the configuration information.
11. IdP FWS gets an SMSESSION cookie for this IdP's domain and calls the Policy Server to validate it. If there is no SMSESSION cookie, the IDP FWS skips redirects or posts to the Authentication URL.
12. The Policy Server verifies the validity of the SMSESSION cookie and returns the result.
13. If the SMSESSION cookie does not exist or is not valid, the IDP FWS redirects or posts to the Authentication URL obtained from the configuration information. If the SMSESSION cookie is valid, the IDP FWS requests a SAML 2.0 artifact from the local Policy Server (see step 18).
14. The browser requests the Authentication URL, which is protected by the IdP Web Agent.
15. The IdP Web Agent logs the user in, setting the SMSESSION cookie, and lets the request pass to the Authentication URL.
16. The Authentication URL is the redirect.jsp file, which replays the request to the IdP single sign-on service with the AuthnRequest message.
17. The browser requests the IdP single sign-on service URL. This request is equivalent to the request from step 8, but now the user has a valid SMSESSION cookie.
18. The IdP FWS requests a SAML 2.0 artifact from the local Policy Server, passing the AuthnRequest via an authorization call to the realm obtained from the configuration information.
19. The Policy Server generates the artifact and the corresponding response message based on the configuration information from the Service Provider. It stores the response in the session store.

    The message is stored as a session variable, and is named using the string representation of the artifact message handle.

20. The Policy Server returns the artifact to IdP FWS.
21. Based on the SP configuration information, the IdP FWS redirects the browser to the Assertion Consumer URL at the SP with the URL-encoded artifact as a URL parameter, or it returns a form containing the artifact form-encoded in two hidden form controls.

    The form is wrapped into a JavaScript to auto-POST the data when read by the browser. The Assertion Consumer URL is obtained from the configuration information.

    Note: If the assertion generator indicates that the authentication level for the current session is too low, the IdP FWS redirects to the authentication URL to facilitate step-up authentication.

22. If the artifact was sent as part of a URL, the browser redirects the user to the Assertion Consumer URL with the artifact. If the artifact was returned in a form, then the browser POSTs the artifact to the Assertion Consumer URL.

    The following steps reflect the back-channel call that the SP FWS Assertion Consumer service makes to the IdP FWS Artifact Resolution Service to resolve the artifact into a response message.

    1. The SP FWS obtains the artifact from the GET or POST data, depending on how the IdP FWS is configured to redirect the browser. It then obtains the SOAP endpoint of the Artifact Resolution Service from the IdP configuration information. The configuration data is retrieved by the source ID, which is part of the artifact. After obtaining the SOAP endpoint, the SP FWS makes a back-channel call to the IdP FWS Artifact Resolution service to resolve the artifact into a response message.
    2. The IdP FWS requests the response message from the local Policy Server. The message stored as a session variable is requested using the Java Agent API. The session ID is extracted from the artifact. The session variable name is the string representation of the artifact message handle.
    3. The local Policy Server retrieves the response message from the session server and deletes it after the artifact retrieval.
    4. The local Policy Server returns the response message to the IdP FWS. The IdP FWS returns the response message to the SP FWS Assertion Consumer Service.

    The back-channel call is now complete.

23. The SP FWS obtains the response message from the post data, determines the target resource from the configuration and makes an isProtected call to the Policy Server for the target resource.

    If the assertion is encrypted, the FWS makes a tunnel call, which takes the encrypted assertion and returns the assertion in the clear.

24. The Policy Server returns the realm OID for the target resource.
25. The SP FWS passes the response message to the local Policy Server via a login call with the response message as credentials and the realm OID obtained from the isProtected call.
26. The SAML 2.0 authentication scheme logs the user in using the response message as credentials.
27. The local Policy Server returns OK to the SP FWS.
28. If a success reply is returned, SP FWS creates an SMSESSION cookie for the SP domain, places it in the user's browser and redirects the user to the target URL, which is obtained from the configuration information.

    If login fails, the SP FWS redirects the user to a No Access URL.

29. The user's browser requests the target URL, which is protected by the Web Agent at the SP. Because the user's browser has an SMSESSION cookie, the Web Agent does not challenge the user.