Federation Guides › Federation in Your Enterprise › Federated Transaction Process Flows

Federated Transaction Process Flows

This section contains the following topics:

SAML 1.x Artifact SSO Transaction Flow (Producer-initiated)

SAML 1.x POST SSO Transaction Flow (Producer-initiated)

SAML 2.0 Artifact SSO Transaction Flow (SP-initiated)

SAML 2.0 POST SSO Transaction Flow (SP-initiated)

WS-Federation SSO Transaction Flow (RP-initiated)

WS-Federation SSO Transaction Flow (IP-initiated)

SAML 2.0 Single Logout Transaction Flow (IdP-initiated)

SAML 2.0 Single Logout Transaction Flow (SP-initiated)

WS-Federation Sign-out Transaction Flow (IP-initiated)

WS-Federation Sign-out Transaction Flow (RP-initiated)

Identity Provider Discovery Transaction Flow

SAML 1.x Artifact SSO Transaction Flow (Producer-initiated)

The following illustration shows the flow between a user and the federation components at the producer and consumer sites. The flow shows single sign-on between the sites using the SAML 1.x artifact profile as the method for processing the SAML assertion.

The flow diagram assumes the following information:

The Producer initiates the transaction.
Successful authentication and authorization at each site.
CA SiteMinder® is shown as the producer and consumer only so you can see the processes at each partner. If CA SiteMinder® is the Producer in your environment, review the producer activities in the table. If CA SiteMinder® is the consumer, review the consumer activities in the table.

The following diagram shows the SAML 1.x artifact SSO transaction flow.

Graphic showing the SAML 1.x Artifact Authentication process

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:

Actor	Transaction Process
User Agent (browser)	1. The user makes an initial request to a protected page at the producer site.
CA SiteMinder® as the Producer	2. The Web Agent at the producer site responds with a 401 challenge to the user for credentials.
	3. The user submits credentials, such as the user name and password to the Web Agent.
	4. The Web Agent issues a SMSESSION cookie to the browser for the producer site domain, and allows access to the local page. Log message: Session cookie does not exist, redirecting to authentication url. Checkpoint code: [SSOSAML11_AUTHENTICATIONURL_REDIRECT]
	5. The user clicks a link on the local page to visit the consumer site. This link is the intersite transfer URL. The intersite transfer URL makes a request to the Web Agent at the producer. The Web Agent forwards an IsProtected call to the Policy Server. This URL contains the location of the SAML credential collector and the target URL at the consumer site. Log messages: SAML11 Consumer Configuration is not in cache. Requesting to get from policy server. Checkpoint code: [SSOSAML11_CONSUMERCONFFROMPS_REQ]
	6. The Web Agent makes a request to the Policy Server to generate the assertion. Log messages: Request to policy server for generating saml11 assertion/artifact based on selected profile. Checkpoint code: [SSOSAML11_GENERATEASSERTIONORARTIFACT_REQ]
	7. The Policy Server generates an assertion, places it in the session store, and returns the SAML artifact for the assertion. Log message: Policy server generates the saml11 assertion. Checkpoint code: [SSOSAML11_PSGENERATEASSERTION_RSP] Log message: Policy server stores the assertion in session store Checkpoint code: [SSOSAML11_PSSTOREASSERTIONINSSTORE_REQ] Log message: Policy server returns the wrappedassertion/artifact(based on profile selected) in response message Checkpoint code: [SSO_PSWRAPPEDASSERTION_RSP]
	8. The Web Agent responds with a 302 redirect to the SAML credential collector at the consumer. The redirect contains the artifact and the target URL as query parameters. Log message: Sending artifact to credential collector service url. Checkpoint code: [SSOSAML11_SENDARTIFACTTOCONSUMERURL_RSP]
User Agent (browser)	9. The browser makes a request to the URL for the SAML credential collector at the consumer site.
CA SiteMinder® as the Consumer	10. The SAML credential collector makes an isProtected call to the Policy Server for information about the producer. Log message: IsProtected call to policy server for producer configuration Checkpoint code: SSOSAML11_ISPROTECTEDCALLTOGETPRODUCERCONF_REQ
	11. The Policy Server returns the producer configuration information.
	12. The SAML credential collector uses the producer configuration to make a SAML request to the assertion retrieval service at the producer. Log message: Reading producer configuration from property. Checkpoint code: SSOSAML11_GETPRODUCERCONFFROMPROPERTY_REQ Log message: Backchannel call to resolve the artifact Checkpoint code: [SSOSAML11_RESOLVEARTIFACT_REQ]
CA SiteMinder® as the Producer	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. The assertion is sent to the consumer. Log message: Retrieving assertion from session store Checkpoint code: [SSOSAML11_RETREIVEASSERTIIONFROMSSTORE_REQ] Log message: Received the assertion from session store. Checkpoint code: [SSOSAML11_RECEIVEDASSERTIONFROMSSTORE_RSP] Log message: Sending assertion as artifact response. Checkpoint code: SSOSAML11_SENDARTIFACTRESPONSE_RSP
CA SiteMinder® as the Consumer	14. The SAML credential collector makes a login call to the Policy Server, passing the SAML assertion as credentials. Log message: Obtained the SAML11 assertion as response from artifact resolve call Checkpoint code: [SSOSAML11_GOTARTIFACTRESPONSE_RSP] Log message: Passing response message through login call Checkpoint code: [SSO_RESPONSEMESSAGEINLOGIN_REQ]
	15. The consumer validates the assertion. The user is looked up in the user record. The Policy Server returns a success reply. Log message: Login successful Checkpoint code: [SSO_LOGINSUCEESS_RSP] If the SAML assertion is not valid or a user record cannot be located, a failure reply is returned. Log message: Login failure. Checkpoint code: [SSO_LOGINFAILURE_RSP]
CA SiteMinder® as the Consumer (continued)	16. If the scheme returns a success reply, the SAML credential collector issues a SMSESSION cookie for the consumer domain to the browser. The SAML credential collector also issues a 302 redirect to the target URL. Log message: Creating the smsession cookie for SP domain. Checkpoint code: [SSO_SMSESSIONFORSPDOMAIN_REQ] Log message: Placing smsession in browser. Checkpoint code: [SSO_PLACESMSSESSIONTOBROWSER_REQ] If the scheme returns a failure reply, the SAML credential collector issues a 302 redirect to a no access URL.
User Agent (Browser)	17. The browser makes a request to the target URL at the consumer, which the Web Agent protects.

SAML 1.x POST SSO Transaction Flow (Producer-initiated)

The flow diagram assumes the following information:

The Producer initiates the transaction.
Authentication and authorization is successful at each site.
CA SiteMinder® is shown as the producer and consumer only so you can see the processes at each partner. If CA SiteMinder® is the Producer in your environment, review the producer activities in the table. If CA SiteMinder® is the consumer, review the consumer activities in the table.

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

Graphic showing the SAML 1.x POST Profile Authentication process

The sequence of events is as follows:

Actor	Transaction Process
User Agent (browser)	1. The user makes an initial request to a protected page at the producer site.
CA SiteMinder® as the Producer	2. The Web Agent at the producer site responds with a 401 challenge to the user for credentials. Log message: SMSESSION cookie does not exist, redirecting to Authentication URL. Checkpoint code: [REDIRECT_AUTH_URL]
	3. The user submits credentials, such as the user name and password to the Web Agent.
	4. The Web Agent issues a SMSESSION cookie to the browser for the producer site domain, and allows access to the local page.
	5. The user clicks a link on the local page to visit the consumer site. This link is the intersite transfer URL, which transfers the user to another site. The intersite transfer URL makes a request to the Web Agent at the producer. This URL contains query parameters for the name of the consumer, the location of the SAML credential collector, and the target URL at the consumer site. Log messages: SAML11 Consumer Configuration is not in cache. Requesting to get from policy server. Checkpoint code: [SSOSAML11_CONSUMERCONFFROMPS_REQ]
	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. Log messages: Request to policy server for generating saml11 assertion/artifact based on selected profile. Checkpoint code: [SSOSAML11_GENERATEASSERTIONORARTIFACT_REQ]
	7. The Policy Server generates the assertion and returns it in a digitally signed SAML response. The Policy Server then returns the response to the intersite transfer URL. Log message: Policy server generates the saml11 assertion. Checkpoint code: [SSOSAML11_PSGENERATEASSERTION_RSP]
	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. Log messages: Adding response in form for HTTP post. Checkpoint code: [FWSBASE_POSTDATAFORM_ADD]
User Agent (browser)	9. The browser 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.
CA SiteMinder® as the Consumer	10. The SAML credential collector makes an isProtected call to the Policy Server. Log message: IsProtected call to policy server for producer configuration. Checkpoint code: SSOSAML11_ISPROTECTEDCALLTOGETPRODUCERCONF_REQ
	11. The SAML credential collector makes a login call to the Policy Server for the requested target resource, passing the assertion as credentials. Log message: Reading the configuration to get the target url. Checkpoint code: [SSOSAML11_READTARGETURL_REQ]
	12. If the login succeeds, the SAML Credential Collector generates an SMSESSION cookie for the consumer site domain. Log message: Login successful Checkpoint code: [SSO_LOGINSUCEESS_RSP] Log message: Creating the smsession cookie for SP domain. Checkpoint code: [SSO_SMSESSIONFORSPDOMAIN_REQ]
	13. The SMSESSION cookie is placed in the browser and redirects the user to the target resource. Log message: Placing smsession in browser. Checkpoint code: [SSO_PLACESMSSESSIONTOBROWSER_REQ]
	14. The browser requests the target resource, which is protected by the consumer-side Web Agent. The browser has an SMSESSION cookie for the consumer domain so the Web Agent does not challenge the user.

SAML 2.0 Artifact SSO Transaction Flow (SP-initiated)

The following illustration shows the detailed flow between a user and the components at the Identity Provider and Service Provider. The flow shows single sign-on between the sites using SAML 2.0 artifact profile as the method for processing the SAML assertion.

The flow diagram assumes the following information:

The SP initiates the request for a resource.
Authentication and authorization at the IdP and SP sites is successful.
CA SiteMinder® is shown as the IdP and SP so you can see the processes at each partner. If CA SiteMinder® is the SP in your environment, review the SP activities in the table. If CA SiteMinder® is the IdP, review the IdP activities in the table.

The following diagram shows the SAML 2.0 artifact SSO transaction flow.

Graphic showing the SAML 2.0 Authentication-Artifact Binding process

The sequence of events is as follows:

Actor	Transaction Process
CA SiteMinder® as the SP	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. Log message: SAML2.0 IDP Configuration is not in cache. Requesting to get from policy server. Checkpoint code: [SSOSAML2_IDPCONFFROMPS_REQ]
	3. The local Policy Server returns the IdP configuration to the SP FWS application. FWS caches this information. Log message: Policy server returns SAML2.0 IDP Configuration Checkpoint code: [SSOSAML2_IDPCONFFROMPS_RSP]
	4. SP FWS requests an AuthnRequest message from the local Policy Server through a tunnel call, passing the Provider ID. The request contains the artifact profile in the ProtocolBinding element value. Log message: Get authentication request from policy server Checkpoint code: [SSOSAML2_GETAUTHENTICATIONREQFROMPS_REQ]
	5. The SP Policy Server generates the AuthnRequest message and returns it to the SP FWS application.
	6. The local Policy Server returns the AuthnRequest message to the SP FWS in an HTTP redirect binding. Log message: Policy server returns authentication request. Checkpoint code: [SSOSAML2_GETAUTHENTICATIONREQFROMPS_RSP]
	7. The SP FWS application redirects the user to the IdP Single Sign-on Service URL, which is obtained from the configuration information with the AuthnRequest message. Log message: Service redirecting to SSO URL Checkpoint code: [SSOSAML2_SSOURL_REDIRECT]
User Agent (browser)	8. The browser requests the IdP Single Sign-on Service URL.
CA SiteMinder® as the IdP	9. IdP FWS requests the SP configuration information from the local IdP Policy Server. Log message: SAML2.0 SP configuration is not in cache. Requesting to get from policy server. Checkpoint code: [SSOSAML2_SPCONFFROMPS_REQ]
	10. The local Policy Server returns the configuration, which the FWS application caches. Log message: Policy server returns SAML2.0 SP Configuration Checkpoint code: [SSOSAML2_SPCONFFROMPS_RSP]
	11. The IdP FWS application gets an SMSESSION cookie for this IdP domain. FWS then calls the Policy Server to validate it. If there is no SMSESSION cookie, the FWS application redirects or posts to the Authentication URL. Log message: Session cookie does not exists. Redirecting to authentication URL Checkpoint code: [SSOSAML2_AUTHENTICATIONURL_REDIRECT]
	12. The Policy Server validates the SMSESSION cookie and returns the result. Log message: Request to validate the session. Checkpoint message: [SSOSAML2_SESSIONCOOKIEVALIDATE_REQ]
	13. If the SMSESSION cookie is valid, the IDP FWS requests a SAML 2.0 artifact from the local Policy Server (see step 18). If the SMSESSION cookie is not valid, does not exist or is not valid, the IDP FWS redirects or posts to the Authentication URL. Log message: Session cookie does not exists, redirecting to authentication url. Checkpoint code: [SSOSAML2_AUTHENTICATIONURL_REDIRECT]
User Agent (browser)	14. If the SMSESSION cookie is not valid, the browser requests the Authentication URL, which the IdP Web Agent protects.
CA SiteMinder® as the IdP	15. The IdP Web Agent logs the user in, sets the SMSESSION cookie, and lets the request pass to the Authentication URL. Log message: Service redirecting to SSO URL Checkpoint code: [SSOSAML2_SSOURL_REDIRECT]
	16. The Authentication URL is the redirect.jsp file, which replays the request to the IdP single sign-on service with the AuthnRequest message
User Agent (browser)	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.
CA SiteMinder® as the IdP	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. Log message: Request to policy server for generating saml2 assertion/artifact based on selected profile. Checkpoint code: [SSOSAML2_GENERATEASSERTIONORARTIFACT_REQ]
	19. The Policy Server generates the artifact and the corresponding response message. The message is formed from the Service Provider configuration. 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. Log message: Policy server generates the artifact for the assertion. Checkpoint code: [SSOSAML2_PSGENERATEARTIFACT_REQ] Log message: Policy server stores the assertion in session store. Checkpoint code: [SSOSAML2_PSSTOREASSERTIONINSSTORE_REQ]
	20. The Policy Server returns the artifact to IdP FWS. Log message: Policy server returning the wrappedassertion/artifact based on profile selected in response message. Checkpoint code: [SSO_PSWRAPPEDASSERTION_RSP]
	21. The Policy Server returns the SP configuration information. Log message: Policy server returns SAML2.0 SP Configuration. Checkpoint code: [SSOSAML2_SPCONFFROMPS_RSP] Based on the 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. Log message: Sending artifact to assertion consumer as url parameter. Checkpoint code: [SSOSAML2_SENDINGARTIFACTASURLPARAM_RSP] Returns a form to the user. The form contains the response message, the Assertion Consumer URL, and the JavaScript to auto-POST the form in the browser. Log messages: Adding response in form for HTTP post. Checkpoint code: [FWSBASE_POSTDATAFORM_ADD] 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.
User Agent (browser)	22. The browser posts the response message to the Assertion Consumer URL at the SP.
CA SiteMinder® as the IdP	23. If the artifact is sent as part of a URL, the browser redirects the user to the Assertion Consumer URL with the artifact. If the artifact is returned in a form, then the browser POSTs the artifact to the Assertion Consumer URL. Log messages: Browser posting the response to assertion consumer url. Checkpoint code: [SSOSAML2_POSTASSERTIONTOCONSUMERURL_RSP] The SP FWS Assertion Consumer service makes a back channel call to the IdP FWS Artifact Resolution Service to obtain the artifact. Steps 23a-23d reflect the back-channel call.
	23a. 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. 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 into a response message. Log message: Backchannel call to resolve the artifact. Checkpoint code: [SSOSAML2_RESOLVEARTIFACT_REQ] Log message: Obtained response message from post data for artifact binding. Checkpoint code: SSOSAML2_READRESPONSEARTIFACTDATA_RSP
	23b. 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. Log message: Extracting session id from artifact. Checkpoint code: [SSOSAML2_EXTRACTSESSIONIDFROMARTIFACT_REQ]
	23c. The local Policy Server retrieves the assertion response message from the session store. The Policy Server deletes it after the artifact retrieval. Log message: Retrieving assertion from session store. Checkpoint code: [SSOSAML2_RETREIVEASSERTIIONFROMSSTORE_REQ]
	23d. The local Policy Server obtains the assertion and returns the artifact response to the IdP FWS. The IdP FWS returns the artifact response to the SP FWS Assertion Consumer Service. Log message: Obtained the SAML2 asserion as response from artifact resolve call. Checkpoint code: [ SSOSAML2_GOTARTIFACTRESPONSE_RSP] Log message: Sending assertion as artifact response. Checkpoint code: [SSOSAML2_SENDARTIFACTRESPONSE_RSP] The back-channel call is now complete.
CA SiteMinder® as the SP	24. 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. Log message: Reading the configuration to get the target URL. Checkpoint code: [SSOSAML2_READTARGETURL_REQ] Log message: IsProtected call to policy server for target resource realm Checkpoint code: [SSOSAML2_ISPROTECTEDCALLTOPS_REQ] If the assertion is encrypted, the FWS makes a tunnel call. This call takes the encrypted assertion and returns the assertion in the clear. Log message: Tunnel call to decrypt the assertion. Checkpoint code: [SSOSAML2_DECRYPTASSERTION_REQ]
	25. The Policy Server returns the realm OID for the target resource. Log message: Policy server returns the realm OID for target resource. Checkpoint code: [SSOSAML2_REALMOIDFORTARGETFROMPS_RSP]
	26. 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. Log message: Passing response message through login call. Checkpoint code: [SSO_RESPONSEMESSAGEINLOGIN_REQ] The SAML 2.0 authentication scheme logs the user in using the response message as credentials. Log message: Policy server logs in the user using SAML 2 auth scheme. Checkpoint code: [SAML2_AUTH_COMPLETE]
	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. Log message: Login successful Checkpoint code: [SSO_LOGINSUCEESS_RSP] Log message: Creating the smsession cookie for SP domain Checkpoint code: [SSO_SMSESSIONFORSPDOMAIN_REQ] The browser redirects the user to the target URL, which is obtained from the configuration information. Log message: Redirecting user to target url. Checkpoint code: [SSOSAML2_REDIRECTUSERTARGETURL_REQ] If the login fails, the SP FWS redirects the user to a No Access URL. Log message: Login failure Checkpoint code: [SSO_LOGINFAILURE_RSP]
User Agent (browser)	29. The browser sends a request to the target URL, which is protected by the SP-side Web Agent. The browser has an SMSESSION cookie so the Web Agent does not challenge the user. The user gains access to the resource.

SAML 2.0 POST SSO Transaction Flow (SP-initiated)

The following diagram shows the detailed flow between a user and the components that are deployed at a CA SiteMinder® Identity Provider (IdP) and Service Provider (SP) sites. The flow shows single sign-on between the sites using SAML 2.0 POST profile as the method for processing the SAML assertion.

The flow diagram assumes the following information:

An SP-initiated request for an assertion.
Authentication and authorization at the IdP and SP sites is successful.
CA SiteMinder® is shown as the IdP and SP only so you can see the processes at each partner. If CA SiteMinder® is the SP in your environment, review the SP activities in the table. If CA SiteMinder® is the IDP, review the IdP activities in the table.

The following diagram shows the SAML 2.0 POST SSO transaction flow.

Graphic showing the flow of the SAML 2.0 POST Authentication Process

The sequence of events is as follows:

Actor	Transaction Process
CA SiteMinder® as the SP	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 from the local Policy Server. Log message: SAML2.0 IDP Configuration is not in cache. Requesting to get from policy server Checkpoint code: [SSOSAML2_IDPCONFFROMPS_REQ]
	3. The Policy Server returns the IdP configuration to the SP FWS application. The FWS application caches this information. Log message: Policy server returns SAML2.0 IDP Configuration Checkpoint code: [SSOSAML2_IDPCONFFROMPS_RSP]
	4. The SP FWS application requests an AuthnRequest message from the local SP Policy Server through a tunnel call, passing the Provider ID. Log message: Get authentication request from policy server Checkpoint code: [SSOSAML2_GETAUTHENTICATIONREQFROMPS_REQ]
	5. The SP Policy Server generates the AuthnRequest message and returns it to the SP FWS application.
	6. The SP FWS application gets the AuthnRequest response in an HTTP redirect binding. Log message: Policy server returns authentication request. Checkpoint code: [SSOSAML2_GETAUTHENTICATIONREQFROMPS_RSP]
	7. The SP FWS application redirects the user to the IdP Single Sign-on Service URL. Log message: Service redirecting to SSO URL Checkpoint code: [SSOSAML2_SSOURL_REDIRECT]
User Agent (browser)	8. The browser requests the IdP Single Sign-on Service URL.
CA SiteMinder® as the IdP	9. IdP FWS requests the SP configuration from the local IdP Policy Server. Log message: SAML2.0 SP configuration is not in cache. Requesting to get from policy server. Checkpoint code: [SSOSAML2_SPCONFFROMPS_REQ]
	10. The local Policy Server returns the configuration, which the FWS application caches. Log message: Policy server returns SAML2.0 SP Configuration Checkpoint code: [SSOSAML2_SPCONFFROMPS_RSP]
	11. The IdP FWS application gets an SMSESSION cookie for this IdP domain. The FWS application then calls the Policy Server to validate it. If there is no SMSESSION cookie, it redirects or posts to the Authentication URL. Log message: Session cookie does not exists. Redirecting to authentication URL Checkpoint code: [SSOSAML2_AUTHENTICATIONURL_REDIRECT]
	12. The Policy Server validates the SMSESSION cookie and returns the result. Log message: Request to validate the session. Checkpoint message: [SSOSAML2_SESSIONCOOKIEVALIDATE_REQ]
	13. If the SMSESSION cookie is valid, the IdP FWS skips to step 18. If the SMSESSION cookie is not valid, does not exist or is not valid, the IdP FWS redirects or posts to the Authentication URL. Log message: Session cookie does not exists, redirecting to authentication url. Checkpoint code: [SSOSAML2_AUTHENTICATIONURL_REDIRECT]
User Agent (browser)	14. If the SMSESSION cookie is not valid, the browser requests the Authentication URL, which the IdP Web Agent protects.
CA SiteMinder® as the IdP	15. The IdP Web Agent logs the user in, sets the SMSESSION cookie, and lets the request pass to the Authentication URL. Log message: Service redirecting to SSO URL Checkpoint code: [SSOSAML2_SSOURL_REDIRECT]
	16. The Authentication URL is the redirect.jsp file, which replays the request to the IdP single sign-on service with the AuthnRequest message.
User Agent (browser)	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.
CA SiteMinder® as the IdP	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. Log message: Request to policy server for generating saml2 assertion/artifact based on selected profile. Checkpoint code: [SSOSAML2_GENERATEASSERTIONORARTIFACT_REQ]
	19. The Policy Server generates an assertion that is based on the configuration for the SP, signs it, and returns the assertion wrapped in a response message. Log message: Policy server generates the saml2 assertion. Checkpoint code: [SSOSAML2_PSGENERATEASSERTION_RSP]
	20. The response message is returned to IdP FWS. Log message: Policy server returns the wrappedassertion/artifact(based on profile selected) in response message. Checkpoint code: [SSO_PSWRAPPEDASSERTION_RSP]
	21. The IdP FWS returns a form to the user. The form contains the response message, the Assertion Consumer URL, and the JavaScript to submit the form. Log messages: Adding response in form for HTTP post. Checkpoint code: [FWSBASE_POSTDATAFORM_ADD] Note: If the Policy Server indicates that the current session authentication level is too low, the IdP FWS redirects to the authentication URL as in Step 13 to facilitate step-up authentication.
User Agent (browser)	22. The browser posts the response to the Assertion Consumer URL at the SP.
CA SiteMinder® as 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. Log messages: Reading the configuration to get the target url. Checkpoint code: [SSOSAML2_READTARGETURL_REQ] Log message: Get realm oid for target resource from property Checkpoint code: [SSOSAML2_REALMOIDFORTARGETFROMPROPERTY_RSP] Log message: Tunnel call to decrypt the assertion. Checkpoint code: [SSOSAML2_DECRYPTASSERTION_REQ]
	24. The Policy Server returns the realm OID for the target resource. Log message: Policy server returns the realm oid for target resource. Checkpoint code: [SSOSAML2_REALMOIDFORTARGETFROMPS_RSP]
	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. Log message: Passing response message through login call. Checkpoint code: [SSO_RESPONSEMESSAGEINLOGIN_REQ]
	26. The Policy Server logs the user in using the response message as credentials. Log message: Policy server logs in the user using SAML 2 auth scheme. Checkpoint code: [SAML2_AUTH_COMPLETE]
	27. The local Policy Server returns OK to the SP FWS. Log message: Login successful Checkpoint code: [SSO_LOGINSUCEESS_RSP]
	28. If a success reply is returned, the SP FWS creates an SMSESSION cookie for the SP domain. The FWS application places the cookie in the browser and redirects the user to the target URL. Log message: Redirecting user to target url Checkpoint code: [SSOSAML2_REDIRECTUSERTARGETURL_REQ] If the login fails, the SP FWS redirects the user to a No Access URL. Log message: Login failure Checkpoint code: [SSO_LOGINFAILURE_RSP]
User Agent (browser)	29. The browser sends a request to the target URL, which is protected by the SP-side Web Agent. The browser has an SMSESSION cookie so the Web Agent does not challenge the user. The user gains access to the resource.

WS-Federation SSO Transaction Flow (RP-initiated)

The following illustration shows the flow between a user and the federation components at the Identity Partner (IP) and Resource Partner (RP) sites. The flow shows single sign-on between the sites using the WS-Federation Passive Requestor profile as the method for processing the SAML assertion.

The flow diagram assumes the following information:

The Resource Partner initiates the request for a resource.
Authentication and authorization at each site is successful.
CA SiteMinder® is shown as the IP and RP only so you can see the processes at each partner. If CA SiteMinder® is the IP in your environment, review the IP activities in the table. If CA SiteMinder® is the RP, review the RP activities in the table.

The following diagram shows the WS-Federation SSO transaction flow.

WS-Federation SSO process flow diagram

The sequence of events is as follows:

Actor	Transaction Process
CA SiteMinder® as the RP	1. The user visits an unprotected site selection page at the Resource Partner.
	2. The user clicks on a link to authenticate at the IP. This link points to the Single Sign-on Service at the IP. The link must contain the RP Provider ID and can include optional parameters, such as the wctx parameter.
	3. The IP FWS requests the RP configuration from the local Policy Server. Log message: Trying to fetch Wsfed Resource Partner Configuration from cache Checkpoint code: [SSOWSFED_RESOURCEPARTNERCONFFROMCACHE_REQ] Log message: Wsfed Resource Partner Configuration is not in cache. Requesting to get from policy server. Checkpoint code: [SSOWSFED_RESOURCEPARTNERCONFFROMPS_REQ]
	4. The local Policy Server returns the configuration. Log message: Policy server returns Wsfed Resource Partner Configuration Checkpoint code: [SSOWSFED_RESOURCEPARTNERCONFFROMPS_RSP]
	5. The IP FWS gets the SMSESSION cookie for the IP domain and calls the Policy Server to validate it. If there is no SMSESSION cookie, the IP FWS skips to step 7. Log message: Request to validate the session Checkpoint code: [SSOWSFED_SESSIONCOOKIEVALIDATE_REQ]
	6. The Policy Server validates the SMSESSION cookie and returns the result to the FWS application.
	7. If the SMSESSION cookie does not exist or is not valid, the IP FWS redirects the user to the Authentication URL obtained from the RP configuration. If the SMSESSION cookie is valid, the IP FWS skips to step 12. Log message: Session cookie does not exists, redirecting to authentication url Checkpoint code: [SSOWSFED_AUTHENTICATIONURL_REDIRECT]
User Agent (browser)	8. The browser requests the Authentication URL, which the IP Web Agent protects.
CA SiteMinder® as the IP	9. The IP WA authenticates the user and sets the SMSESSION cookie. The IP WA lets the request pass to the Authentication URL.
	10. The Authentication URL replays the request to the IP SSO service with the original wsignin message.
User Agent (browser)	11. The browser requests the IP SSO Service URL. This request is equivalent to the request from step 2, but now the user has a valid SMSESSION cookie.
CA SiteMinder® as the IP	12. The IP FWS requests a WS-Federation <RequestSecurityTokenResponse> from the Policy Server through an authorize call to the realm obtained from the configuration. Log message: Request to policy server for generating Wsfed assertion. Checkpoint message: [SSOWSFED_GENERATEASSERTION_REQ]
	13. The Policy Server generates a SAML1.1 assertion that is based on the RP configuration. Log message: Policy server generates the samlxx assertion for wsfed12. Checkpoint code: [SSOWSFED12_PSGENERATESAML11ASSERTION_RSP]
	14. The Policy Server signs the assertion and returns it to the IP FWS application in an <RequestSecurityTokenResponse> message. Log message: Policy server signs the Assertion element of the RequestSecurityTokenResponse Checkpoint code: Differs for different SAML protocols. [SSOWSFED10_PSGENERATELEGACYASSERTION_RSP] [SSOWSFED12_PSGENERATESAML12ASSERTION_RSP] [SSOWSFED_PSSIGNASSERTION_RSP]
	15. The IP FWS returns a form to the user containing the URL encoded <RequestSecurityTokenResponse> message, the Security Token Consumer Service URL, the Optional wctx in the wsignin message, and the 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. The Security Token Consumer URL in the RP configuration takes precedence over the wreply parameter. Note: The Policy Server can indicate that the authentication level of the current session is too low. If the level is too low, the IP FWS application redirects the browser to the authentication URL as in step 7 to facilitate step-up authentication. Log message: Received the assertion response. Checkpoint code: [SSOWSFED_RECEIVEDASSERTION_RSP]
User Agent (browser)	16. The browser posts the <RequestSecurityTokenResponse> message and wctx to the Security Token Consumer URL at the RP.
CA SiteMinder® as the RP	17. The RP FWS application obtains the <RequestSecurityTokenResponse> message and wctx from the POST data. The RP FWS application requests the IP configuration from the local Policy Server. Log message: Browser posting the response to security token consumer service url. Checkpoint code: [SSOWSFED_POSTASSERTIONTOSECURITYTOKENCONSUMER_RSP] Log message: Extracting the assertion from security token consumer response Checkpoint code: [SSOWSFED_EXTARCTASSERTIONFROMSECURITYTOKENRESPONSE_REQ]
	18. RP FWS determines the target resource from the IP configuration from local Policy Server. If the target resource is not part of the IP configuration, and the wctx parameter is found in the POST data, the wctx value becomes the target resource. Log message: Request to get the target url realm. Checkpoint code: [SSOWSFED_GETTARGETURLREALM_REQ]
	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.
CA SiteMinder® as the RP (continued)	21. The RP FWS application 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 RP FWS application logs in the user with the <RequestSecurityTokenResponse> message as credentials.
	23. The local Policy Server returns an OK status message to the RP FWS application.
	24. The RP FWS application generates the SMSESSION cookie for the RP domain. FWS puts the cookie in the browser and redirects the user to the Target URL or to the wctx POST data. If the login fails, the FWS application redirects the user to a No Access URL. Log message: Redirecting user to target url. Checkpoint code: [SSOWSFED_REDIRECTUSERTARGETURL_REQ]
User Agent (browser)	25. The user agent requests the Target URL that the RP-side Web Agent protects. The browser has the SMSESSION cookie for the RP domain, so the Web Agent does not have to challenge the user.

WS-Federation SSO Transaction Flow (IP-initiated)

IP-initiated single sign-on is similar to an RP-initiated transaction. The main difference is the few actions that take place at the IP before the user is sent to the RP.

At the IP, the following actions occur:

The user selects a link for a specific partner site. This link is part of the HTML content at the IP, which contains intersite transfer links to different RP sites.
The link directs the web browser to the IP SSO Service URL.
The SSO service redirects the browser to the RP, where the rest of the processing is same as specified in the RP-initiated SSO transaction flow.

SAML 2.0 Single Logout Transaction Flow (IdP-initiated)

The following illustration shows the detailed flow for a single logout (SLO) request between a user and the components that are deployed at a CA SiteMinder® Identity Provider (IdP) and Service Provider (SP). This flow shows single logout for all entities that have a session with a particular user.

The flow diagram assumes the following information:

An IdP initiates the log out request.
The HTTP-Redirect binding is in use.
CA SiteMinder® is shown as the IdP and SP only so you can see the processes at each partner. If CA SiteMinder® is the SP in your environment, review the SP activities in the table. If CA SiteMinder® is the IDP, review the IdP activities in the table.

The following illustration shows the SLO transaction flow. When the IdP initiates SLO, several SPs can receive the SLO request.

IdP_initiated SLO transaction flow

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:

Actor	Transaction Process
CA SiteMinder® as the IdP	1. The user clicks a logout link at the IdP. The browser accesses the Single Logout servlet at the IdP. The IdP FWS application renames the SMSESSION cookie to SESSIONSIGNOUT to invalidate the current user session. Log message: Renaming session cookie to sessionsignout cookie. Checkpoint code: [SLO_SESSION_RENAME]
	2. The IdP FWS application reads the SessionID value from the SESSIONSIGNOUT cookie and sends a request to the IdP Policy Server to terminate the user session. Log message: Fetching session details from cookie. Checkpoint code: [SLO_SESSION_FETCH] Depending on the request type (GET or POST), one of the corresponding checkpoint messages are logged: Log message: Receiving request at SAML2 SLO Logout URL through GET method. Checkpoint code: [SLOSAML2_LOGOUTSERVICEGET_RECEIVE] or Log message: Receiving request at SAML2 SLO Logout URL through POST method. Checkpoint code: [SLOSAML2_LOGOUTSERVICEPOST_RECEIVE]
	3. The IdP Policy Server determines all of the SPs where the user was logged in.
	4. Based on the session store information, the user session status for the first SP in the list is changed to a LogoutInProgress state. The Policy Server generates a LogoutRequest request to invalidate the user session at the SP. Log message: Generating SAML LogoutRequest. Checkpoint code: [SLO_LOGOUTREQUEST_GEN]
	5. The Policy Server returns a LogoutRequest request to IdP FWS. The Policy Server also returns the Provider ID of the SP and provider type. Log message: Generating SAML LogoutRequest. Checkpoint code: [SLO_LOGOUTREQUEST_GEN]
	6. The IdP FWS application retrieves the provider configuration data of the SP from the Policy Server. The data includes the SLO service URL at the SP. Log message: Fetching provider information. Checkpoint code: [SLOSAML2_PROVIDERINFO_FETCH]
	7. The IdP FWS application redirects the user to the SP SLO service with the LogoutRequest message added as a query parameter. Log message: Redirecting to service providers single logout service url. Checkpoint code: [SLOSAML2_SPSLOSERVICEURL_FORWARD]
User Agent (browser)	8. The browser accesses SLO service at the SP.
CA SiteMinder® as the SP	9. The SP FWS application receives and processes the LogoutRequest message. Log message: Receiving request at SAML2 SLO Logout URL through GET method. Checkpoint code: [SLOSAML2_LOGOUTSERVICEGET_RECEIVE] or Log message: Receiving request at SAML2 SLO Logout URL through POST method. Checkpoint code: [SLOSAML2_LOGOUTSERVICEPOST_RECEIVE] The SP renames the SMSESSION cookie to SESSIONSIGNOUT. Log message: Renaming session cookie to sessionsignout cookie. Checkpoint code: [SLO_SESSION_RENAME]
	10. The SP removes the user session from the SP session store. Log message: Logging out session cookie. Checkpoint code: [SLO_SESSIONCOOKIE_LOGOUT] Log message: Terminating user session from session store. Checkpoint code: [SLO_USERSESSION_TERMINATE]
	11. The SP Policy Server returns a signed LogoutResponse message to the SP FWS application. This response contains the provider ID of the IdP and the provider type. The Policy Server also informs the application that the user session is no longer in the session store. Log message: Generating SAML LogoutResponse. Checkpoint code: [SLO_LOGOUTRESPONSE_GEN]
	12. After learning that the user session is removed from the session store, the SP FWS application deletes the SESSIONSIGNOUT cookie. Log message: Terminating user session from session store. Checkpoint code: [SLO_USERSESSION_TERMINATE]
	13. The SP FWS application redirects the user to the IdP SLO service with the LogoutResponse message added as a query parameter. The browser accesses the SLO service at the IdP. The service processes the signed LogoutResponse message. Note: If the LogoutResponse message contains non-SUCCESS return code, the SP issues a SIGNOUTFAILURE cookie. 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. Log message: Redirecting to identity provider single logout service url. Checkpoint code: [SLOSAML2_IDPSLOSERVICEURL_FORWARD]
CA SiteMinder® as the IdP	14. The IdP Policy Server receives the LogoutResponse message and processes it.
	15. The SP Policy Server removes the user session from the session store. Log message: Terminating user session from session store. Checkpoint code: [SLO_USERSESSION_TERMINATE]
	16. The IdP Policy Server checks for any more SPs. If there are more, the flow repeats, beginning at step 4. Otherwise, the process continues to the next step.
	17. After the session is removed from the session store, the IdP Policy Server sends a SUCCESS return code to the FWS application. The Policy Server includes the SP ID in the final LogoutResponse message.
	18. If there are no more LogoutRequest or LogoutResponse messages to process, the IdP FWS application deletes the SESSIONSIGNOUT cookie.
	19. The browser redirects the user to the Logout Confirmation page at the SP. Log message: Redirecting to SLO confirmation URL. Checkpoint code: [SLOSAML2_LOGOUTCONFIRMURL_REDIRECT] Log message: Displaying local logout message / URL. Checkpoint code: [SLO_LOCALLOGOUT_DISPLAY]

SAML 2.0 Single Logout Transaction Flow (SP-initiated)

The following illustration shows the detailed flow for a single logout (SLO) request between a user and the components deployed at a CA SiteMinder® Identity Provider (IdP) and Service Provider (SP). This flow shows single logout for all entities that have a session with a particular user.

The flow diagram assumes the following information:

An SP initiates the log out request.
The HTTP-Redirect binding is in use.
CA SiteMinder® is shown as the IdP and SP only so you can see the processes at each partner. If CA SiteMinder® is the SP in your environment, review the SP activities in the table. If CA SiteMinder® is the IDP, review the IdP activities in the table.

The following illustration shows the SLO transaction flow.

Graphic showing a Single Logout process flow

The sequence of events is as follows:

Actor	Transaction Process
CA SiteMinder® as the SP	1. The user clicks a logout link at SP. The browser accesses the Single Logout servlet at the SP. The SP FWS application renames the SMSESSION cookie to SESSIONSIGNOUT to invalidate the current user session. Log message: Renaming session cookie to sessionsignout cookie. Checkpoint code: [SLO_SESSION_RENAME]
	2. The FWS application reads the SessionId value from the SESSIONSIGNOUT cookie and sends a request to the Policy Server to terminate the user session. Log message: Fetching session details from cookie. Checkpoint code: [SLO_SESSION_FETCH] Depending on the request type (GET or POST), one of the corresponding checkpoint messages are logged: Log message: Receiving request at SAML2 SLO Logout URL through GET method. Checkpoint code: [SLOSAML2_LOGOUTSERVICEGET_RECEIVE] or Log message: Receiving request at SAML2 SLO Logout URL through POST method. Checkpoint code: [SLOSAML2_LOGOUTSERVICEPOST_RECEIVE]
	3. Based on the session store information, the user session status is changed to a LogoutInProgress state. The Policy Server determines that the user session is created based on the assertion received from an IdP. The Policy Server generates a LogoutRequest request to invalidate the user session at the IdP. Log message: Generating SAML LogoutRequest. Checkpoint code: [SLO_LOGOUTREQUEST_GEN] Log message: Identifying providers associated with user session for single logout. Checkpoint code: [SLO_PROVIDERFORLOGOUT_IDENTIFY]
	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. Log message: Generating SAML LogoutRequest. Checkpoint code: [SLO_LOGOUTREQUEST_GEN]
	5. The SP FWS application retrieves the provider configuration data of the IdP from the Policy Server. The data includes the SLO service URL at the IdP. Log message: Fetching provider information. Checkpoint code: [SLOSAML2_PROVIDERINFO_FETCH]
	6. The SP FWS application redirects the user to the SLO service at the IdP with the SAML LogoutRequest message added as a query parameter. Log message: Redirecting to identity provider single logout service url. Checkpoint code: [SLOSAML2_IDPSLOSERVICEURL_FORWARD]
User Agent (browser)	The browser accesses SLO service at the IdP.
CA SiteMinder® as the IdP	7. The IdP FWS application receives a LogoutRequest message. Depending on the request type (GET or POST), one of the corresponding checkpoint messages are logged: Log message: Receiving request at SAML2 SLO Logout URL through GET method. Checkpoint code: [SLOSAML2_LOGOUTSERVICEGET_RECEIVE] or Log message: Receiving request at SAML2 SLO Logout URL through POST method. Checkpoint code: [SLOSAML2_LOGOUTSERVICEPOST_RECEIVE] The IdP renames the SMSESSION cookie to SESSIONSIGNOUT. Log message: Renaming session cookie to sessionsignout cookie. Checkpoint code: [SLO_SESSION_RENAME]
	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 the same from Step 2 through Step 7. Log message: Logging out session cookie. Checkpoint code: [SLO_SESSIONCOOKIE_LOGOUT]
	9. After terminating the user session from all relevant SPs, the IdP removes the user session from the session store. Log message: Terminating user session from session store. Checkpoint code: [SLO_USERSESSION_TERMINATE] 10. The IdP Policy Server returns a signed LogoutResponse message to the IdP FWS application. This response contains the provider ID of the SP and the provider type. The IdP Policy Server also informs the application that the user session is no longer in the session store. Log message: Generating SAML LogoutResponse. Checkpoint code: [SLO_LOGOUTRESPONSE_GEN]
	11. After learning that the user session is removed from the session store, the IdP FWS application deletes the SESSIONSIGNOUT cookie.
CA SiteMinder® as the IdP (continued)	12. The IdP redirects the user to the single logout service at the SP with the LogoutResponse message added as a query parameter. The browser accesses the SLO service at the SP. The service processes the signed LogoutResponse message. Note: If the LogoutResponse message contains non-SUCCESS return code, the SP 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. Log message: Redirecting to service providers single logout service url. Checkpoint code: [SLOSAML2_SPSLOSERVICEURL_FORWARD]
CA SiteMinder® as the SP	13. The SP Policy Server receives the LogoutResponse message from the FWS application and processes it.
	14. The SP Policy Server removes the user session from the session store. Log message: Terminating user session from session store. Checkpoint code: [SLO_USERSESSION_TERMINATE]
CA SiteMinder® as the SP (continued)	15. After the session is removed from the session store, the Policy Server sends a SUCCESS return code to the FWS application. The Policy Server includes the SP ID in the final LogoutResponse message.
	16. If there are no more LogoutRequest or LogoutResponse messages to process, the SP FWS application deletes the SESSIONSIGNOUT cookie.
	17. FWS redirects the user to the Logout Confirmation page at the SP. Log message: Redirecting to SLO confirmation URL. Checkpoint code: [SLOSAML2_LOGOUTCONFIRMURL_REDIRECT] Log message: Displaying local logout message / URL. Checkpoint code: [SLO_LOCALLOGOUT_DISPLAY]

WS-Federation Sign-out Transaction Flow (IP-initiated)

The following illustration shows the flow for a signout request between a user and the components that are deployed at an Identity Provider (IP) and Resource Partner (RP). This flow shows a sign-out transaction for all WS-Federation entities that have a session with a particular user.

The flow diagram assumes the following information:

The IP initiates the signout transaction.
CA SiteMinder® is shown as the IP and RP so you can see the processes at each partner. If CA SiteMinder® is the IP in your environment, review the IP activities in the table. If CA SiteMinder® is the RP, review the RP activities in the table.

The following illustration shows the WS-Federation sign-out transaction flow.

Transaction flow of IP-initiated WS-Fed Sign-out

When sign-out is initiated at the Identity Provider, the sequence of events is as follows:

Actor	Transaction Process
CA SiteMinder® as the IP	1. The user clicks a link at the IP to end the global session. The browser sends an HTTP-based wsignout request to the signout servlet at the IP.
	2. The IP FWS application renames the SMSESSION cookie to SESSIONSIGNOUT to invalidate the current user session. Log message: Renaming session cookie to sessionsignout cookie. Checkpoint code: [SLO_SESSION_RENAME]
	3. The IP FWS reads the SessionId value from the SESSIONSIGNOUT cookie and calls the SLO Tunnel Service API to terminate the user session. Log message: Fetching session details from cookie. Checkpoint message: SLO_SESSION_FETCH Log message: Performing tunnel call for WSFED signout. Checkpoint code: [SLOWSFED_TUNNEL_REQUEST]
	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. Log message: Setting session to inactive assuming a cleanup state. Checkpoint code: [SLOWSFED_INACTIVESTATE_SET]
	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. Log message: Terminating user session from session store. Checkpoint code: [SLO_USERSESSION_TERMINATE]
	6. The IP FWS retrieves the provider configuration data of the RP from the cache of the provider that FWS maintains. The information includes the signout cleanup URL. Log message: Validate GET request for necessary parameters. Checkpoint code: [SLOWSFED_GETREQUEST_VALIDATE]
	7. The IP FWS removes the SESSIONSIGNOUT cookie and posts an IP Signout message and multiple RP-SignoutCleanup locations as POST data to the SignoutConfirmURL JSP. Log message: Logging out session cookie. Checkpoint code: [SLO_SESSIONCOOKIE_LOGOUT] The SignoutConfirmURL JSP is responsible for parsing various post variables and creating a frame-based HTML page. The main frame of this HTML page displays the IP-SignOut message. Each of the remaining frames accesses the SignoutCleanupURL of individual RPs associated with the user session. Log message: Sending signout message to Identity Provider (Account Partner). Checkpoint code: [SLOWSFED_IDPSIGNOUTMSG_SEND] Log message: Redirecting to signout confirmation URL Checkpoint code: [SLOWSFED_LOGOUTCONFIRMURL_REDIRECT]
User Agent (browser)	8. The browser accesses the SignoutCleanup service at the RP.
CA SiteMinder® as the RP	9. When the RP FWS application receives a wsignoutcleanup request, it renames the SMSESSION cookie to SESSIONSIGNOUT. FWS then calls the SLO Tunnel Service API to process the wsignoutcleanup request. Log message: Renaming session cookie to sessionsignout cookie. Checkpoint code: [SLO_SESSION_RENAME] Log message: Receiving signout request at WSEFD through GET method Checkpoint code: [SLOWSFED_LOGOUTSERVICEGET_RECEIVE]
	10. The SLO tunnel library processes the wsignoutcleanup request and terminates the user session from the session store. Log message: Terminating user session from session store. Checkpoint code: [SLO_USERSESSION_TERMINATE]
	11. The SLO tunnel library returns FWS with a "Terminated" status message indicating that the user session no longer exists in the session store. Log message: Logging out session cookie. Checkpoint code: [SLO_SESSIONCOOKIE_LOGOUT]
	12. The FWS Signout Servlet removes the SESSIONSIGNOUT cookie and returns a 200 OK response in the frame. Log message: Displaying local logout message / URL. Checkpoint message: [SLO_LOCALLOGOUT_DISPLAY]

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

WS-Federation Sign-out Transaction Flow (RP-initiated)

The flow diagram assumes the following information:

The RP initiates the signout transaction.
CA SiteMinder® is shown as the IP and RP so you can see the processes at each partner. If CA SiteMinder® is the IP in your environment, review the IP activities in the table. If CA SiteMinder® is the RP, review the RP activities in the table.

The following illustration shows the sign-out request transaction flow.

RP-initiated WS-Federation signout transaction flow

When sign-out is initiated at the Resource Partner, the process flow is as follows:

Actor	Transaction Process
CA SiteMinder® as the RP	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. The RP FWS application reads the SessionId value from the SMSESSION cookie. The application renames the SMSESSION cookie to SESSIONSIGNOUT, and calls the SLO tunnel library with the wsignout request. Log message: Renaming session cookie to sessionsignout cookie. Checkpoint code: [SLO_SESSION_RENAME] Log message: Performing tunnel call for WSFED signout. Checkpoint code: [SLOWSFED_TUNNEL_REQUEST]
	3. Based on information in the session store, the tunnel library determines the IP associated with the user session. The SLO tunnel library sets the user session state to SignoutInProgress, but does not terminate it. Log message: Sending signout message and awaiting response from ap for cleanup. Checkpoint code: [SLOWSFED_AWAITINGRESPONSE_SEND]
	4. The tunnel library returns the SignoutInProgress state message and the IP providerID and providerType. Log message: Performing tunnel call for WSFED signout. Checkpoint code: [SLOWSFED_TUNNEL_REQUEST]
	5. The RP FWS application retrieves the IP configuration data, which includes the Signout URL from the FWS cache or Policy Server.
	6. The RP FWS application redirects the browser to the Signout URL. 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. Log message: Redirecting to signout confirmation URL. Checkpoint code: [SLOWSFED_LOGOUTCONFIRMURL_REDIRECT]
CA SiteMinder® as the IP	7. The IP FWS application removes the SESSIONSIGNOUT cookie then posts an IP 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 IP-SignOut message. Each of the remaining frames accesses the SignoutCleanupURL of individual RPs associated with the user session. Log message: Sending signout message and awaiting response from ap for cleanup. Checkpoint code: [SLOWSFED_AWAITINGRESPONSE_SEND] Log message: Sending signout cleanup message. Checkpoint code: [SLOWSFED_CLEANUPMESSAGE_SEND]
User Agent (browser)	8. The browser accesses SignoutCleanup service at the Resource Partner site in an individual frame.
CA SiteMinder® as the RP (continued)	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. Log message: Renaming session cookie to sessionsignout cookie. Checkpoint code: [SLO_SESSION_RENAME]
	10. The SLO tunnel library processes the wsignoutcleanup request and terminates the user session from the session store. Log message: Terminating user session from session store. Checkpoint code: [SLO_USERSESSION_TERMINATE] 11. Then SLO tunnel library returns FWS with a Terminated status message indicating that the user session no longer exists in the session store. Log message: Redirecting to signout confirmation URL. Checkpoint code: [SLOWSFED_LOGOUTCONFIRMURL_REDIRECT]
	12. The FWS Signout Servlet removes the SESSIONSIGNOUT cookie and returns a 200 OK response in the frame. Log message: Displaying local logout message / URL. Checkpoint message: [SLO_LOCALLOGOUT_DISPLAY]

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

Identity Provider Discovery Transaction Flow

The following illustration shows the flow for a single sign-on transaction using the Identity Provider Discovery profile. The Identity Provider Discovery (IPD) profile provides a common discovery service that enables a Service Provider to select a unique IdP for authentication. A prior business agreement between partners is established so that all sites in the network interact with the Identity Provider Discovery service.

In this diagram, an Identity Provider Discovery service sits between the user and the federation components at a CA SiteMinder® Identity Provider. This flow redirects a request from an Identity Provider to the Identity Provider Discovery service to set the common domain cookie.

The flow diagram assumes the following information:

The SP FWS redirects the user to the IdP SSO Service URL to initiate the transaction.
SAML 2.0 HTTP POST is the single sign-on profile.
CA SiteMinder® is shown as the IdP so you can see the processes at each partner.

The following illustration shows the flow of an Identity Provider Discovery transaction.

Identity Provider Discovery Transaction Flow

The Identity Provider Discovery process is as follows.

Actor	Transaction Process
User Agent (browser)	1. The user clicks on a link to initiate an authentication request.
CA SiteMinder® as the SP	2. The SP FWS requests the IdP configuration information from the local Policy Server. Log message: Reading SAML 2.0 IDP Configuration Checkpoint code: [SSOSAML2_IDPCONFREAD_REQ]
	3. The local Policy Server returns the configuration information. Note: The SP FWS application can cache the configuration information. Log message: Policy server returns SAML2.0 IDP Configuration Checkpoint code: [SSOSAML2_IDPCONFFROMPS_RSP]
	4. The SP FWS redirects the request to the browser.
User Agent (browser)	5. The user agent (browser) requests the IdP SSO Service.
CA SiteMinder® as the IdP	6. The IdP FWS requests the SP configuration information from the local Policy Server. Log message: SAML2.0 SP Configuration is not in cache. Requesting to get from policy server. Checkpoint code: [SSOSAML2_SPCONFFROMPS_REQ]
	7. The local Policy Server returns the configuration information. Note: The IdP FWS application can cache the configuration information. Log message: Policy server returns SAML2.0 SP Configuration. Checkpoint code: [SSOSAML2_SPCONFFROMPS_RSP]
	8. 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. Log message: Request to validate the session. Checkpoint code: [SSOSAML2_SESSIONCOOKIEVALIDATE_REQ]
	9. The Policy Server validates the SMSESSION cookie and returns the result.
	10. 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. Log message: Session cookie does not exists. redirecting to authentication url Checkpoint code: [SSOSAML2_AUTHENTICATIONURL_REDIRECT]
User Agent (browser)	11. The browser requests the Authentication URL. The IdP Web Agent protects the Authentication URL.
CA SiteMinder® as the IdP	12. The IdP Web Agent logs the user in, setting the SMSESSION cookie and lets the request pass to the Authentication URL.
	13. The Authentication URL replays the request to the IdP SSO Service with the AuthnRequest message. Log message: Policy server returns the authentication request Checkpoint code: [SSOSAML2_GETAUTHENTICATIONREQFROMPS_RSP] Log message: Service redirecting to SSO URL Checkpoint code: [SSOSAML2_SSOURL_REDIRECT]
User Agent (browser)	14. The browser requests the IdP SSO Service. This request is equivalent to the request from step 8, but now the user has a valid SMSESSION cookie.
CA SiteMinder® as the IdP	15. The IdP FWS requests the Identity Provider Discovery Profile (IPD) configuration from the Policy Server, passing the Identity Provider ID. Log message: Request for IPD configuration Checkpoint code: [SSOIPD_READIPDCONF_REQ]
	16. The Policy Server returns with the IPD configuration, including IPD Service URL, common domain cookie, and persistence information of the common domain cookie. Log message: Reading IPD service URL from configuration Checkpoint code: [SSOIPD_READIPDSERVICEURL_REQ] Log message: Reading common domain cookie from configuration Checkpoint code: [SSOIPD_READCOMMONDOMAINCOOKIE_REQ] Log message: Reading persistence information of the common domain cookie Checkpoint code: [SSOIPD_READPERSISTENCEINFOFORCOMMONCOOKIE_REQ]
	17. The IdP FWS application redirects the call to the IPD Service URL. Log message: Redirecting to IPD service URL Checkpoint code: SSOIPD_REDIRECTTOIPDURL_REQ
User Agent (browser)	18. The browser redirects the user to the IPD Service to set the common domain cookie.
Identity Provider Discovery Service	19. 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. Log message: IPD service setting common domain cookie with identity provider id Checkpoint code: [SSOIPD_SETCOMMONDOMAINCOOKIE_REQ]
User Agent (browser)	20. The browser makes a request to the IdP SSO Service.
CA SiteMinder® as the IdP	21. 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. Log message: Request to policy server for generating saml2 assertion/artifact based on selected profile. Checkpoint code: [SSOSAML2_GENERATEASSERTIONORARTIFACT_REQ]
	22. 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 in a response message. Log message: Policy server generates the saml2 assertion Checkpoint code: [SSOSAML2_PSGENERATEASSERTION_RSP] Log message: Policy server signs saml2 assertion Checkpoint code: [SSOSAML2_PSSIGNASSERTION_RSP]
	23. The response message is returned to the IdP FWS. Log message: Received the assertion/artifact response based on profile selected. Checkpoint code: [SSOSAML2_RECEIVEDASSERTION_RSP]
	24. The IdP FWS returns a form to the user containing the response message and the Assertion Consumer URL obtained from the configuration, and the Javascript to submit the form. Log message: Browser posting the response to assertion consumer url Checkpoint code: SSOSAML2_POSTASSERTIONTOCONSUMERURL_RSP Note: The Policy Server 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 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.