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

Flow Diagram for SSO Using SAML 2.0 Authentication with POST Binding

The illustration that follows shows the detailed flow between a user's browser and the Federation Security Service components deployed at an Identity Provider (IdP) and Service Provider (SP) sites. This set-up enables single sign-on between the sites, using SAML 2.0 POST binding as the method of obtaining the SAML assertion for authentication.

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-POST 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 Policy Server returns the IdP configuration information to SP FWS. FWS may cache this configuration information.
4. SP FWS requests an AuthnRequest message from the local Policy Server via a tunnel call, passing the Provider ID.
5. The 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 Single Sign-on Service URL, which is obtained from the configuration information with the AuthnRequest message.
8. The browser requests the IdP Single Sign-on Service 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 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 skips to 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 request a SAML 2.0 assertion from the Policy Server, passing the AuthnRequest via an authorize call to the realm obtained from the configuration information.
19. The Policy Server generates an assertion based on the configuration information for the SP, signs it, and returns the assertion wrapped in a response message.
20. The response message is returned to IdP FWS.
21. IdP FWS returns a form to the user, which contains the response message, the Assertion Consumer URL, obtained from the configuration information and the JavaScript to submit the form.

    Note: If the assertion generator returns an indication that the current sessions authentication level too low, the IdP FWS redirects to the authentication URL as in Step 13, to facilitate step-up authentication.

22. The user's browser posts the response message to the Assertion Consumer URL at the SP.
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 to 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.