Federation Security Services Guide › Federation Security Services Overview › Federation Security Services Process Flow › Flow Diagram for WS-Federation SSO Initiated at the Resource Partner

Flow Diagram for WS-Federation SSO Initiated at the Resource Partner

The illustration that follows shows the detailed flow between a user's browser and the Federation Security Service components deployed at an Account Partner (AP) and Resource Partner (RP) sites. This set-up enables single sign-on between the sites, using WS-Federation as the method of obtaining the SAML assertion for authentication.

The flow diagram assumes the following:

• The Resource Partner initiates the request for a resource.
• Successful authentication and authorization at the AP and RP sites.

  

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 WS-Federation single sign-on process is as follows:

1. The user visits an unprotected site selection page at the Resource Partner.
2. The user chooses a link to authenticate for AP that is a federated partner. This link actually points to the Single Sign-on Service at the AP, and must contain the Provider ID of the RP and may include some optional parameters, such as the wctx parameter. The browser requests the AP SSO Service URL.
3. Based on RP provider ID specified as a query parameter, the AP FWS requests the RP configuration information from the local Policy Server.
4. The local Policy Server returns the configuration information. Note that the FWS may cache the configuration information.
5. The AP FWS gets the SMSESSION cookie for the AP domain and calls the Policy Server to validate it. If there is no SMSESSION cookie, the AP FWS skips to step 7.
6. The Policy Server verifies the validity of the SMSESSION cookie and returns the result to the FWS application.
7. If the SMSESSION cookie does not exist or is not valid, the AP FWS redirects the user to the Authentication URL obtained from the RP configuration information. If the SMSESSION cookie is valid, the AP FWS skips to step 12.
8. The browser requests the Authentication URL which is protected by the AP Web Agent (WA).
9. The AP WA authenticates the user, sets the SMSESSION cookie and lets the request pass to the Authentication URL.
10. The Authentication URL points to the redirect.jsp, which replays the request to the AP SSO service with the original wsignin message.
11. The browser requests the AP SSO Service URL. This request is equivalent to the request from step 2, but now the user has a valid SMSESSION cookie
12. The AP FWS requests a WS-Federation <RequestSecurityTokenResponse> from the Policy Server via an authorize call to the realm obtained from the configuration information.
13. The Policy Server generates a SAML1.1 assertion based on the configuration information for the RP, signs it, and returns the assertion wrapped in an <RequestSecurityTokenResponse> message.
14. The <RequestSecurityTokenResponse> message is returned to the AP FWS.
15. The AP FWS returns a form to the user containing the following:
    • URL encoded <RequestSecurityTokenResponse> message
    • Security Token Consumer Service URL
    • Optional wctx that came with the wsignin message
    • JavaScript to auto submit the form.

    If the original wsignin request contains the wreply parameter, its value is used as Security Token Consumer URL, only if Security Token Consumer URL config setting is not specified in RP configuration information. For security reasons, the Security Token Consumer URL setting in the RP configuration information takes precedence over the value specified for the wreply parameter.

    Note: If the assertion generator indicates that the current session's authentication level is too low, the AP FWS redirects to the authentication URL as in step 7 to facilitate "step-up" authentication.

16. The user agent posts the <RequestSecurityTokenResponse> message and wctx to the Security Token Consumer URL at the RP.
17. The RP FWS obtains the <RequestSecurityTokenResponse> message and wctx from the POST data. RP FWS requests the AP configuration information from the local Policy Server.
18. RP FWS determines the target resource from the AP configuration information received from local Policy Server. If target resource is not specified as part of AP configuration, and the wctx parameter is found in the POST data, its value is used as target resource.
19. FWS makes an isProtected call to the Policy Server for the target resource.
20. The Policy Server returns the realm OID for the target resource.
21. The RP FWS passes the <RequestSecurityTokenResponse> message to the local Policy Server via a login call with the <RequestSecurityTokenResponse> message as credentials and the realm OID obtained from the isProtected call.
22. The WS-Federation authentication scheme logs the user in using the <RequestSecurityTokenResponse> message as credentials.
23. The local Policy Server returns an OK status message to the RP FWS.
24. The RP FWS creates a SMSESSION cookie for the RP domain, places it in the user's browser and redirects the user to the Target URL obtained from the configuration information or to the wctx POST data. If login fails the RP FWS redirects the user to a No Access URL.
25. The user agent requests the Target URL that is protected by the Web Agent at the RP. Since the user's browser has a SMSESSION cookie for the RP domain, the Web Agent does not have to challenge the user.