Federation Security Services Guide › Federation Security Services Process Flow

Federation Security Services Process Flow

This section shows the detailed flow between the components that comprise the SiteMinder Federated Security Services. This section assumes that the reader knows SiteMinder interactions between a Web Agent and Policy Server.

This section contains the following topics:

Flow Diagram for SSO Using SAML 1.x Artifact Authentication

Flow Diagram for SSO Using SAML 1.x POST Profile Authentication

Flow Diagram for SSO Using SAML 2.0 Authentication with Artifact Binding

Flow Diagram for SSO Using SAML 2.0 Authentication with POST Binding

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

Flow Diagram for SAML 2.0 Single Logout

Flow Diagram for WS-Federation Signout (AP-initiated)

Flow Diagram for WS-Federation Signout (RP-initiated)

Flow Diagram for Identity Provider Discovery Profile

Flow Diagram for SSO Using SAML 1.x Artifact Authentication

The following illustration shows the flow between a user and the Federation Security Services components at the producer and consumer sites. This set-up enables single sign-on between the sites. SAML artifact profile is the authentication method and the flow diagram assumes successful authentication and authorization at the producer and consumer sites.

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

The process flow diagram for SAML 1.x Artifact Authentication follows.

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the 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 Secure Proxy Server Administration Guide.

The sequence of actions is as follows:

1. The user makes an initial request to a protected page at the producer site.
2. The Web Agent at the producer site responds with a 401 challenge to the user.
3. The user submits credentials, such as the user name and password to the Web Agent.
4. The Web Agent issues a SiteMinder SMSESSION cookie to the browser of the user for the producer site domain.
5. The user clicks a link to visit the consumer site. This link is referred to as the intersite transfer URL because it results in transferring the user to another site. The intersite transfer URL makes a request to the Web Agent at the producer site first. This URL contains the location of the SAML credential collector and the target URL to access at the consumer site.
6. The Web Agent at the producer site handles the intersite transfer URL request by calling the assertion generator.
7. The assertion generator generates a SAML assertion, places it in the session store and returns the SAML artifact for the assertion.
8. The Web Agent responds with a 302 redirect to the SAML credential collector at the consumer. The redirect contains the SAML artifact and the target URL as query parameters.
9. The browser makes a request to the URL for the SAML credential collector at the consumer site.
10. The SAML credential collector handles the URL request by making an isProtected call to the SAML artifact authentication scheme.
11. The SAML artifact authentication scheme returns the producer configuration information.
12. The SAML credential collector uses the producer configuration information to make a SAML request to the assertion retrieval service at the producer. In this step, the SAML credential collector is acting as an HTTP client.
13. The assertion retrieval service at the producer retrieves the SAML assertion from the session store. The service responds with a SAML response that contains the SAML assertion.
14. The SAML credential collector makes a login call to the SAML artifact authentication scheme, passing the SAML assertion as credentials.
15. The SAML artifact authentication scheme validates the SAML assertion. The authentication scheme looks up the user record. The lookup is based on the user mapping that is configured for the scheme. The scheme returns a success reply. If the SAML assertion is not valid or a user record cannot be located, the scheme returns a failure reply.
16. If the scheme returns a success reply, the SAML credential collector issues a SiteMinder SMSESSION cookie for the consumer domain to the browser. The SAML credential collector also issues a 302 redirect to the target URL. If the scheme returns a failure reply, the SAML credential collector issue a 302 redirect to a no access URL.
17. The browser makes a request to the target URL at the consumer, which the Web Agent protects.

Flow Diagram for SSO Using SAML 1.x POST Profile Authentication

The following illustration shows the detailed flow between a user and the components at producer and consumer sites. This set-up enables single sign-on between the sites. SAML POST profile is the authentication method and the illustration assumes successful authentication and authorization at the producer and consumer sites.

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

The process flow diagram for SAML 1.x POST Profile follows.

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the 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 Secure Proxy Server Administration Guide.

The sequence of events is as follows:

1. User requests a local page at the producer, which the Web Agent protects.
2. The Web Agent at the producer asks for user credentials.

   This flow diagram assumes that the resource is protected with basic authentication and that user name and password are the required credentials.

3. The user submits credentials.
4. The Agent at the producer issues an SMSESSION cookie for the producer site domain and allows access to the local page.
5. The user selects a link at the local page of the producer to visit the consumer. The link looks like it goes to the consumer site, but it goes to the intersite transfer URL. The URL contains the affiliate name, the assertion consumer URL, and the target resource as query parameters.
6. The Intersite Transfer Service makes an IsProtected call to the Policy Server for the resource. The URL contains the name query parameter that uniquely identifies the consumer.
7. The Policy Server recognizes the request as a request for a SAML assertion. The Policy Server generates the assertion and returns it in a digitally signed SAML response message. The Policy Server then returns the response to the intersite transfer URL.
8. The intersite transfer URL service generates an auto-POST form containing the encoded SAML response and the target URL as form variables. The service sends the form to the browser.
9. The browser of the user automatically posts the HTML form to the SAML Credential Collector at the consumer site. This URL is read from the SAML response that the intersite transfer URL service sends.
10. The Credential Collector makes an isProtected call to the SAML POST profile authentication scheme. The authentication scheme informs the assertion consumer what type of credentials are required.
11. The Credential collector makes a login call for the requested target resource to the SAML POST profile authentication scheme, passing the assertion as credentials.
12. If the login succeeds, the SAML Credential Collector generates an SMSESSION cookie for the consumer site domain.
13. The SMSESSION cookie is placed in the browser and redirects the user to the target resource.
14. The browser requests the target resource, which the consumer-side Web Agent protects. The browser has an SMSESSION cookie for the consumer domain so the Web Agent does not challenge the user.

Flow Diagram for SSO Using SAML 2.0 Authentication with Artifact Binding

The following illustration shows the detailed flow between a user and the components 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 the artifact binding as the authentication method.

The flow diagram assumes the following information:

• 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 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 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 can cache the configuration information.
4. SP FWS requests an AuthnRequest message from the local Policy Server through 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. FWS obtains the configuration information and includes it in 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: FWS can cache the configuration information.

11. IdP FWS gets an SMSESSION cookie for the domain of this IdP 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. 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 the IdP Web Agent protects.
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. FWS passes the AuthnRequest through an authorization call to the realm obtained from the configuration information.
19. The Policy Server generates the artifact and the corresponding response message. The message is formed from the configuration information from the Service Provider. The Policy Server 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 takes one of the following actions:
    • Redirects the browser to the Assertion Consumer URL at the SP. The URL-encoded artifact is a URL parameter. The Assertion Consumer URL is obtained from the configuration information.
    • 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 the browser reads it.

    Note: The assertion generator can indicate that the authentication level for the current session is too low. If the level 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. FWS then obtains the SOAP endpoint of the Artifact Resolution Service from the IdP configuration information. The source ID is part of the artifact. After the SOAP endpoint is obtained, the SP FWS makes a back-channel call to the IdP FWS Artifact Resolution service to resolve the artifact.
    2. The IdP FWS requests the response message from the local Policy Server. The message that is 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 store 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. The service then 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. This call 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 through a login call. The response message acts as the credentials and the realm OID is 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. The service places the cookie in the browser and redirects the user to the target URL, which is obtained from the configuration information.

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

29. The browser of the user requests the target URL, which the SP-side Web Agent protects. Because the browser has an SMSESSION cookie, the Web Agent does not challenge the user.

Flow Diagram for SSO Using SAML 2.0 Authentication with POST Binding

The following illustration shows the detailed flow between a user and the 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 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 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 can cache this configuration information.
4. SP FWS requests an AuthnRequest message from the local Policy Server through 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: FWS can cache the configuration information.

11. IdP FWS gets an SMSESSION cookie for this domain of the IdP 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. FWS obtains this URL from the configuration information. If the SMSESSION cookie is valid, the IDP FWS skips to 18.
14. The browser requests the Authentication URL, which the IdP Web Agent protects.
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 assertion from the Policy Server. The AuthnRequest goes through an authorize call to the realm obtained from the configuration information.
19. The Policy Server generates an assertion that is 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. The form 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 indicates 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 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. FWS then 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. The call 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 through a login call. FWS uses 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. FWS then places the cookie in the browser and redirects the user to the target URL, which is obtained from the configuration information.

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

29. The browser sends a request to the target URL, which the SP-side Web Agent protects. Because the browser has an SMSESSION cookie, the Web Agent does not challenge the user.

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

The following illustration shows the detailed flow between a user and the Federation Security Services components 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 information

• 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 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 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 points to the Single Sign-on Service at the AP. The link must contain the Provider ID of the RP and can 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: The FWS can 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 the AP Web Agent protects.
9. The AP WA authenticates the user and sets the SMSESSION cookie. The AP WA 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 through an authorize call to the realm obtained from the configuration information.
13. The Policy Server generates a SAML1.1 assertion that is based on the configuration information for the RP. The Policy Server signs the assertion and returns it 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 information:
    • 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 becomes the Security Token Consumer URL. The wreply value becomes the URL only if the Security Token Consumer URL setting is not in the RP configuration information. For security reasons, the Security Token Consumer URL setting in the RP configuration information takes precedence over the wreply parameter.

    Note: The assertion generator can indicate that the authentication level of the current session is too low. If the 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 from local Policy Server. If the target resource is not part of the AP configuration, and the wctx parameter is found in the POST data, the wctx value becomes the 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 through a login call. The <RequestSecurityTokenResponse> message and the realm OID obtained from the isProtected call service as credentials.
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 the SMSESSION cookie for the RP domain. FWS places the cookie in the browser and redirects the user to the Target URL or to the wctx POST data. If the login fails, the RP FWS redirects the user to a No Access URL.
25. The user agent requests the Target URL that the RP-side Web Agent protects. Because the browser has the SMSESSION cookie for the RP domain, the Web Agent does not have to challenge the user.

WS-Federation SSO Initiated at the Account Partner

Single sign-on that is initiated by the Account Partner is similar to the RP-initiated use case. HTML content at AP contains intersite transfer links to different RP sites. When the user clicks any link, the web browser requests the AP SSO Service URL. The rest of the processing is same as specified in the RP-initiated use case.

Flow Diagram for SAML 2.0 Single Logout

The following illustration shows the detailed flow for a single logout request between a user and the Federation Security Services components at an Identity Provider (IdP) and Service Provider (SP). This set-up enables single logout for all entities that have a session with a particular user.

The following illustration assumes that the SP initiates the log out request.

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack, which provide the FWS application functions. For more 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 clicks a link at SP to end the global session. The browser of the user accesses the Single Logout servlet at the SP.

   SP FWS renames the SMSESSION cookie to SESSIONSIGNOUT to invalidate the current session of the user.

2. FWS reads the SessionId value from the SESSIONSIGNOUT cookie and asks the Policy Server to terminate the user session.
3. Based on the session store information, the user session status is changed to a LogoutInProgress state in the session store. The Policy Server determines that the user session is created based on the SAML assertion received from an IdP. The Policy Server generates a LogoutRequest request to invalidate the user session at the IdP.
4. The Policy Server returns a LogoutRequest request to SP FWS. The Policy Server also returns the Provider ID of the IdP and provider type.
5. SP FWS retrieves the provider configuration data of the IdP, which includes the SLO service URL, from the Policy Server.
6. SP FWS redirects the user to the SLO service at the IdP with the SAML LogoutRequest message added as a query parameter.
7. The browser of the user accesses SLO service at the IdP.

   When the IdP FWS receives a LogoutRequest message, it renames the SMSESSION cookie to SESSIONSIGNOUT.

8. The IdP processes the signed LogoutRequest message. The IdP then tries to invalidate the user session at all SPs specified in the session store for that session. The only SP that is not invalidated is the SP that sent the original LogoutRequest.

   Note: The process for logging the user out at each SP is similar to Step 2 through Step 7.

9. After terminating the user session from all relevant SPs, the IdP removes the user session from the session store.
10. The IdP Policy Server returns a signed LogoutResponse message to the IdP FWS, containing the provider ID of the SP and provider type. The IdP Policy Server also informs FWS that the user session is removed from the session store.
11. After learning that the user session is removed from the session store, IdP FWS deletes the SESSIONSIGNOUT cookie.
12. The IdP FWS redirects the user to the single logout service at the SP with the SAML LogoutResponse message added as a query parameter. The single logout service is part of the SP FWS application.

    The browser of the user accesses SLO service of the SP, which processes the signed LogoutResponse message.

    If the LogoutResponse message contains non-SUCCESS return code, FWS issues a SIGNOUTFAILURE cookie, and a base 64-encoded Partner ID is appended to the cookie value. If there are multiple IDs in the cookie, a space character separates them.

13. The SP Policy Server receives the LogoutResponse message from FWS and processes it.
14. The SP Policy Server removes the user session from the session store.
15. After the session is removed from the session store, the Policy Server sends a SUCCESS return code to FWS. The Policy Server includes the SP ID in the final LogoutResponse message.
16. If there are no more LogoutRequest or LogoutResponse messages to process, SP FWS deletes the SESSIONSIGNOUT cookie.
17. FWS redirects the user to the Logout Confirmation page at the SP.

Flow Diagram for WS-Federation Signout (AP-initiated)

The following illustration shows the flow for a signout request between a user and the Federation Security Services components deployed at an Account Partner (AP) and Resource Partner. This set-up enables signout for all entities that have a session with a particular user.

The following illustration assumes that the AP initiates the signout request.

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack, which provide the FWS application functions. For more information about installing and configuring the SPS federation gateway, see the CA SiteMinder Secure Proxy Server Administration Guide.

When signout is initiated at the Account Partner, the process flow is as follows:

1. The user clicks on a link at the Account Partner to end the global session. The browser of the user sends a HTTP-based wsignout request to the signout servlet at the Account Partner.
2. FWS renames the SMSESSION cookie to SESSIONSIGNOUT to invalidate the current session of the user.
3. FWS reads the SessionId value from the SESSIONSIGNOUT cookie and calls the SLO Tunnel Service API to terminate the user session from the session store.
4. The SLO Tunnel Service API sets the user session status to "Terminated" in the session store. The service also removes all the RP references from the session store that are associated with that user session.
5. The SLO Tunnel Service API returns the logout status "Terminated" to the FWS Signout Servlet. The Tunnel library also returns the RP providerID and providerType for all the RPs associated with the user session.
6. FWS retrieves the provider configuration data of the RP, which includes the signout cleanup URL, from the cache of the provider maintained in FWS.
7. FWS removes the SESSIONSIGNOUT cookie then posts an AP Signout message and multiple RP-SignoutCleanup locations as post data to the SignoutConfirmURL JSP. The SignoutConfirmURL JSP is responsible for parsing various post variables and creating a frame-based HTML page. The mainframe in this HTML page displays the AP-SignOut message. Each of the remaining frames accesses the SignoutCleanupURL of individual RPs associated with the user session.
8. The browser of the user accesses SignoutCleanup service at the Resource Partner site in an individual frame.
9. When the RP FWS (Signout Servlet) receives a wsignoutcleanup request, it renames the SMSESSION cookie to SESSIONSIGNOUT. FWS then calls the SLO Tunnel Service API to process the wsignoutcleanup request.
10. The SLO tunnel library processes the wsignoutcleanup request and terminates the user session from the session store.
11. Then SLO tunnel library returns FWS with a "Terminated" status message indicating that the user session no longer exists in the session store.
12. The FWS Signout Servlet removes the SESSIONSIGNOUT cookie and returns a 200 OK response in the frame.

Note: Steps 8-12 are repeated for individual RPs simultaneously in different frames of the same HTML page.

Flow Diagram for WS-Federation Signout (RP-initiated)

The following illustration shows the flow for a signout request between a user and the Federation Security Services components at an Account Partner (AP) and Resource Partner. This set-up enables signout for all entities that have a session with a particular user.

The following illustration assumes that the RP initiates the sign out request.

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack, which provide the FWS application functions. For more information about installing and configuring the SPS federation gateway, see the CA SiteMinder Secure Proxy Server Administration Guide.

When signout is initiated at the Resource Partner, the process flow is as follows:

1. The user clicks a link at the Resource Partner to end the global session. The browser sends a HTTP-based wsignout request to the Signout servlet at the Resource Partner.

   Note: The RP site is receiving a wsignout message and not a wsignoutcleanup message.

2. FWS reads the SessionId value from the SMSESSION cookie, renames the SMSESSION cookie to SESSIONSIGNOUT, and calls the SLO tunnel library with the wsignout request.
3. Based on information in the session store, the tunnel library determines determines the AP associated with the user session. The SLO tunnel library sets the user session state to SignoutInProgress, but does not terminate it.
4. The tunnel library returns the SignoutInProgress state message and the Account Partner providerID and providerType.
5. FWS retrieves Account Partner configuration data, which includes the Signout URL, from the FWS cache or Policy Server.
6. FWS redirects the browser of the user to the Signout URL.
7. FWS removes the SESSIONSIGNOUT cookie then posts an AP signout message and multiple RP-SignoutCleanup locations as post data to the SignoutConfirmURL JSP. The SignoutConfirmURL JSP is responsible for parsing various post variables and creating a frame-based HTML page. The primary frame in this HTML page displays the AP-SignOut message. Each of the remaining frames accesses the SignoutCleanupURL of individual RPs associated with the user session.
8. The browser accesses SignoutCleanup service at the Resource Partner site in an individual frame.
9. When RP FWS (Signout Servlet) receives a wsignoutcleanup request, it renames the SMSESSION cookie to SESSIONSIGNOUT. The service then calls the SLO Tunnel Service API to process the wsignoutcleanup request.
10. The SLO tunnel library processes the wsignoutcleanup request and terminates the user session from the session store.
11. Then SLO tunnel library returns FWS with a Terminated status message indicating that the user session no longer exists in the session store.
12. The FWS Signout Servlet removes the SESSIONSIGNOUT cookie and returns a 200 OK response in the frame.

Note: Steps 8-12 are repeated for individual RPs simultaneously in different frames of the same HTML page.

Flow Diagram for Identity Provider Discovery Profile

The following illustration shows the flow for an Identity Provider Discovery service between the user and the Federation Security Services components at an Identity Provider. This set-up involves redirecting from an Identity Provider to the Identity Provider Discovery Profile service to set the common domain cookie.

The following illustration assumes that the SP FWS redirects the user to the IdP SSO Service URL.

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the 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 Secure Proxy Server Administration Guide.

The Identity Provider Discovery process is as follows:

1. The user agent (browser) requests the IdP SSO Service URL.
2. The IdP FWS requests the SP configuration information from the local Policy Server.
3. The local Policy Server returns the configuration information.

   Note: The FWS can cache the configuration information.

4. The IdP FWS gets the SMSESSION cookie for the IdP domain and calls to the Policy Server to validate it. If there is no SMSESSION cookie, the IdP FWS skips to Step 6.
5. The Policy Server verifies the validity of the SMSESSION cookie and returns the result.
6. 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. If the SMSESSION cookie is valid, the IdP FWS skips to Step 18.
7. The user agent requests the Authentication URL. The IdP Web Agent protects the Authentication URL.
8. The IdP Web Agent logs the user in, setting the SMSESSION cookie and lets the request pass to the Authentication URL.
9. The Authentication URL is the redirect.jsp file, which replays the request to the IdP SSO Service with the AuthnRequest message.
10. The user agent requests the IdP SSO Service URL. This request is equivalent to the request from step 8, but now the user has a valid SMSESSION cookie.
11. The IdP FWS requests the Identity Provider Discovery Profile (IPD) configuration from the Policy Server, passing the Identity Provider ID.
12. The Policy Server returns with the IPD configuration, such as IPD Service URL, common domain cookie, and persistence information of the common domain cookie.
13. The IdP FWS redirects the user to the IPD Service URL to set the common domain cookie.
14. The IdP FWS redirects the user to the IPD Service URL.
15. The IPD Service sets or updates the common domain cookie with the Identity Provider ID. The IPD Service redirects the user agent back to the IdP FWS from which it received the Set Request.
16. The user agent requests the IdP SSO Service URL.
17. The IdP FWS requests a SAML 2.0 assertion from the Policy Server, passing the AuthnRequest through an authorize call to the realm obtained from the configuration.
18. The Policy Server generates an assertion that is based on the configuration information for the Service Provider. The Policy Server signs the assertion and returns the assertion wrapped in a response message.
19. The response message is returned to the IdP FWS.
20. The IdP FWS returns a form to the user containing the response message, the Assertion Consumer URL obtained from the configuration and Javascript to submit the form.

    Note: The assertion generator can indicate that the authentication level of the current session is too low. If the level is too low, the IdP FWS redirects to the authentication URL as in Step 13 to facilitate step-up authentication.

After the final step in the diagram, the user agent posts the response message to the Assertion Consumer URL at the Service Provider.