Previous Topic: CA SiteMinder® Federation DeploymentsNext Topic: Federation Deployment Considerations

Federation Guides › Federation in Your Enterprise › Federation Use Cases and Solutions

Federation Use Cases and Solutions

This section contains the following topics:

Use Case: Single Sign-on Based on Account Linking

Use Case: Single Sign-on Based on User Attributes

Use Case: Single Sign-on with No Local User Account

Use Case: SAML 2.0 Single Logout

Use Case: WS-Federation Sign-out

Use Case: Identity Provider Discovery Profile

Use Case: Federation with Multiple SSO Profiles

Use Case: SAML 2.0 User Authorization Based on a User Attribute

Use Case: Single Sign-on with No Name ID at the IdP

Use Case: SSO Using Security Zones

Use Case: SSO with Dynamic Account Linking at the SP

Use Case: Single Sign-on Based on Account Linking

In this use case, smcompany.com contracts with a partner, ahealthco.com to manage employee health benefits.

An employee of smcompany.com authenticates at an employee portal at the company website, smcompany.com and clicks a link to view her health benefits at ahealthco.com. The employee is taken to the ahealthco.com web site and is presented with the correct health benefit information without having to sign on to the website.

The following illustration shows this use case.

Graphic showing SSO based on account linking

Account linking can be used for browser-based single sign-on, where each partner maintains separate user accounts for the same user. Account linking uses the SAML assertion to associate a federated identifier with the local identity at a partner.

In this use case, ahealthco.com maintains all health-related information and user identities for every employee at smcompany.com. When an employee of smcompany.com accesses ahealthco.com, an identifier for the employee is passed from smcompany.com to ahealthco.com in a secure manner. This identifier allows ahealthco.com to determine who the user is and the level of access to allow for that user.

Solution: Single Sign-on based on Account Linking

Federation can be deployed at smcompany.com and ahealthco.com to solve Use Case: Single Sign-on Based on Account Linking.

Graphic showing the SSO solution for account linking

CA SiteMinder® is deployed at both sites. The Web Agent with the Web Agent Option Pack are installed on a webserver system and the Policy Server is installed on another system. The installations are the same for smcompany.com and ahealthco.com.

The FWS application provides the servlets which retrieve assertions for the HTTP-Artifact profile and which consume assertions.

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the Federation Web Services application functions. For information about installing and configuring the SPS federation gateway, see the Secure Proxy Server Administration Guide.

Account Linking Solution: SAML 1.1 HTTP-Artifact Profile

In this example, smcompany.com is the producer. The administrator at smcompany.com configures a SAML 1.1 producer-to-consumer partnership between smcompany.com and ahealthco.com. This partnership uses the HTTP-Artifact profile for single sign-on.

The partnership at smcompany.com has the following information:

An employee of smcompany.com logs into the company site and is initially authenticated by the Web Agent. The employee of smcompany.com accesses the employee portal web site and the sequence of events is as follows:

  1. The employee clicks a link at smcompany.com to view health benefits at ahealthco.com. The link makes a request to the Intersite Transfer Service at smcompany.com.
  2. The Intersite Transfer Service calls the Policy Server and sends a request that the Policy Server generate an assertion and artifact. The Policy Server generates an assertion and places assertion in the session store. It also generates and returns the artifact to the service.
  3. The Web Agent redirects the user to ahealthco.com with the SAML artifact.

Ahealthco.com is the consumer site. The administrator at ahealthco.com configures a consumer-to-producer partnership with smcompany.com. This partnership uses the HTTP-Artifact profile for single sign-on.

The partnership configuration has the following information:

Ahealthco.com receives the assertion and the sequence of events follows:

  1. The browser posts the response to the SAML credential collector URL.
  2. The service sends a request with the SAML artifact to the assertion retrieval service at smcompany.com. The assertion retrieval service extracts the session ID from the artifact.
  3. The assertion retrieval service obtains the assertion from the session store. It sends the assertion as an artifact response to the SAML credential collector at ahealthco.com.
  4. The SAML credential collector validates the assertion. The Policy Server creates a session and places a session cookie in the browser for the ahealthco.com domain.
  5. The SAML credential collector redirects the user to the target resources at ahealthco.com.
Account Linking Solution: SAML 1.x POST Profile

In this example, smcompany.com is the producer. The administrator at smcompany.com configures a producer-to-consumer partnership. The partnership uses SAML 1.x POST profile for single sign-on.

The partnership configuration has the following information:

When an employee of smcompany.com accesses the employee portal site, the sequence of events is as follows:

  1. The Web Agent provides the initial authentication.
  2. The employee clicks a link at smcompany.com to view the health benefits at ahealthco.com. The link makes a request to the Intersite Transfer Service at smcompany.com.
  3. The Intersite Transfer Service calls the assertion generator, which creates a SAML assertion and signs the SAML response.
  4. The signed response is placed in an auto-POST HTML form and sent to the user's browser.
  5. The browser posts a form containing the response to the Assertion Consumer Service at ahealthco.com..

Ahealthco.com is the consumer site. The SAML credential collector service at ahealthco.com handles the SAML response. The administrator at ahealthco.com configures a consumer-to-producer partnership with smcompany.com that uses the SAMl 1.1 HTTP-POST profile for single sign-on.

The partnership configuration has the following information:

The sequence of events is as follows:

  1. The SAML credential collector receives the assertion from the producer.
  2. The SAML credential collector calls the Policy Server at ahealthco.com.
  3. The Policy Server verifies the signature of the assertion then uses it to authenticate the user.
  4. After successful authentication, the Policy Server creates an SMSESSION cookie and places it in the browser
  5. The browser redirects the user to the target resource at ahealthco.com.
Account Linking Solution: SAML 2.0 Artifact Profile

In this example, smcompany.com is the Identity Provider. The administrator at smcompany.com configures an IdP-to-SP partnership with ahealthco.com as the remote SP.

The partnership configuration contains the following information:

An employee accesses the employee portal site and the following sequence of events occurs:

  1. The Web Agent provides the initial authentication.
  2. The user clicks a link to view health benefits at ahealthco.com. Because the request is initiated at the Identity Provide, the request triggers an unsolicited response.
  3. Federation Web Services (FWS) requests the SAML artifact from Policy Server.
  4. The Policy Server generates a SAML assertion and an artifact. The Policy Server stores the assertion in the session store, and the artifact as a URL parameter.
  5. The Policy Server returns the response containing the SAML artifact to FWS.
  6. The Web Agent redirects the user with the SAML artifact to ahealthco.com.

Ahealthco.com is the Service Provider. The administrator at ahealthco.com configures an SP-to-IdP partnership with smcompany.com, which uses the artifact profile. The partnership configuration has the following information:

The sequence of events is as follows:

  1. The Assertion Consumer Service receives the artifact. The service obtains the location of the Artifact Resolution Service at smcompany.com from its partnership configuration.
  2. The Assertion Consumer Service makes a call across the back channel to the Artifact Resolution Service at smcompany.com.
  3. The Policy Server retrieves the assertion from the session store and returns the response to the Assertion Consumer Service at ahealthco.com.
  4. The Assertion Consumer Service validates the response and creates the session for ahealthco.com. A session cookie is written to the browser.
  5. The browser redirects the user to the target resource at ahealthco.com.
Account Linking Solution: SAML 2.0 POST Profile

In this example, smcompany.com is the Identity Provider. The administrator at smcompany.com configures an IdP-to-SP partnership. The partnership uses SAML 2.0 HTTP-POST profile for single sign-on.

The partnership configuration has the following information:

An employee of smcompany.com logs in to the employee portal site.

After a successful initial authentication, the following sequence occurs:

  1. The Web Agent at smcompany.com initially authenticates the user.
  2. The employee clicks a link to ahealthco.com to view health benefits. The Policy Server reads the SAML 2.0 SP configuration.

    The Identity Provider initiates the request, which triggers an unsolicited response.

  3. A request is sent to the Single Sign-on (SSO) service at smcompany.com.
  4. The SSO service makes a request to policy server to generate a SAML 2.0 assertion/artifact based on the selected profile. For HTTP-POST, the Policy Server generates a SAML assertion.
  5. The SSO service receives the assertion response for the selected profile.
  6. The signed response is placed in an auto-POST HTML form and sent to the browser.
  7. The browser POSTs the response to the Assertion Consumer Service at ahealthco.com.

Ahealthco.com is the Service Provider. The administrator at ahealthco.com configures an SP-to-IdP partnership with smcompany.com. The configuration uses the SAML 2.0 HTTP-POST profile for single sign-on.

The partnership configuration has the following information:

The sequence of events at ahealthco.com is as follows:

  1. The Assertion Consumer Service obtains the response message from the post data.
  2. The Assertion Consumer Service reads the IdP configuration to get the target URL.
  3. The Assertion Consumer Service passes the signed SAML response as credentials to the Policy Server at ahealthco.com.
  4. The Policy Server verifies the signature and then authenticates the user.
  5. The login is successful.
  6. The Policy Server creates an SMSESSION cookie for the ahealthco.com domain and places the cookie in the browser.
  7. The browser redirects the user to the target resource at ahealthco.com.
Account Linking Solution: WS-Federation Passive Requestor Profile

In this example, smcompany.com is the Identity Provider. The administrator at smcompany.com configures a WSFED IP-to-RP partnership. The partnership uses the WS-Federation Passive Requester profile for single sign-on. In this use case, ahealthco.com, the Resource Partner, initiates single sign-on.

The SAML token type is SAML 1.1. This part of the IP entity configuration.

The partnership configuration has the following information:

When an employee of smcompany.com accesses the employee portal, the following sequence of events occurs:

  1. The user visits an unprotected site selection page at ahealthco.com. The Web Agent provides the initial authentication.
  2. The user clicks a link that points to the Single Sign-on Service at smcompany.com. The browser redirects the user to smcompany.com.
  3. The SSO Service calls the Policy Server. The Policy Server generates the assertion.
  4. The Policy Server signs the assertion element of the Request Security Token Response and returns a response.
  5. The browser POSTS the response in an auto-POST HTML form to the Security Token Consumer Service at ahealthco.com.

Ahealthco.com is the Resource Partner.

The partnership configuration has the following information:

The sequence of events is as follows:

  1. The Security Token Consumer Service extracts the assertion from the security token consumer response.
  2. The service determines the target resource.
  3. The Security Token Consumer Service passes the signed assertion as credentials to the Policy Server at ahealthco.com.
  4. The Policy Server verifies the signature and then authenticates the user.
  5. After successful authentication, the Security Token Consumer Service creates an SMSESSION cookie.
  6. The service then places the cookie in the browser and redirects the user to the target resource at ahealthco.com.

Use Case: Single Sign-on Based on User Attributes

In Use Case 2, smcompany.com buys parts from a business partner named partsco.com.

An engineer authenticates at smcompany.com and clicks a link to access information at partsco.com. As an engineer at smcompany.com, the user is taken directly to the Specifications portion of the partsco.com website without having to log in.

A buyer for smcompany.com authenticates and clicks a link for partsco.com. The buyer is taken directly to the Parts List portion of the partsco.com website. The buyer does not have to log in.

The following graphic shows the relationship between the two partners.

Graphic of single sign-on based on user attributes

Other attributes, such as the user name are passed from smcompany.com to partsco.com to personalize the interface for the individual user.

Partsco.com does not want to maintain user identities for all smcompany.com employees, but the company wants to control access to sensitive portions of the website. To control the access, partsco.com maintains a limited number of identities for users at smcompany.com. One identity is maintained for Engineers and one identity is maintained for Buyers.

When an employee of smcompany.com accesses partsco.com, smcompany.com sends user attributes in a secure manner to partsco.com. Partsco.com uses the attributes to determine which identity controls access for the user.

Solution: Single Sign-on based on User Attributes

Federation can be deployed at smcompany.com and partsco.com to solve Use Case: Single Sign-on Based on User Attribute Profiles.

The illustration is similar for SAML 1.1, SAML 2.0, and WS-Federation.

Graphic of SSO solution with user attributes

CA SiteMinder® is deployed at both sites. The interaction between the user and each site is similar, where partsco.com is acting as the relying party. The Federation Web Services application contains all the necessary servlets to process the transaction.

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the Federation Web Services application functions. For information about installing and configuring the SPS federation gateway, see the Secure Proxy Server Administration Guide.

The sequence of events is similar to the solution for Single Sign-on based on Account Linking, except for the following items:

Use Case: Single Sign-on with No Local User Account

In this use case, smcompany.com offers employee discounts by establishing a partnership with discounts.com.

An employee authenticates at smcompany.com and clicks a link to access discounts.com. The employee is taken to the discounts.com website and is presented with the discounts available for smcompany.com employees, without logging in to the discounts.com website.

The following illustration shows this use case.

Graphic of single sign-on with no local user account

Discounts.com does not maintain any identities for smcompany.com. The company allows all employees of smcompany.com to access discounts.com as long as they have been authenticated at smcompany.com. Smcompany.com sends authentication information about the user requesting a resource to discounts.com in a secure manner so access is permitted.

Solution: Single Sign-on with no Local User Account

Federation is deployed at smcompany.com and discounts.com to solve Use Case: Single Sign-on with No Local User Account.

The following figure shows single sign-on with no local user account. SAML 1.1 is the SSO profile in use.

Graphic showing SSO at the SP with no local user account

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the Federation Web Services application functions. For information about installing and configuring the SPS federation gateway, see the Secure Proxy Server Administration Guide.

In this deployment, CA SiteMinder® is at both sites. Smcompany.com is the SAML 1.1 producer. The administrator at smcompany.com configures a SAML 1.1 partnership that includes a remote entity representing discounts.com. Any attributes that are configured in the partnership get included in the assertion.

For this solution to work, every user must map to a single user account, making the single user essentially an anonymous user.

When an smcompany.com employee accesses the employee portal, the following process occurs:

  1. The Web Agent provides initially authenticates.
  2. The employee clicks a link to access deals at discounts.com. This link is referred to as the intersite transfer URL because it results in transferring the user to another site.
  3. The intersite transfer URL makes a request to the Web Agent. This URL contains the location of the SAML credential collector and the target URL at the consumer site.
  4. The Web Agent at smcompany.com calls the Policy Server. The Policy Server generates an assertion and an artifact, and stores the assertion in the session store.
  5. The Policy Server returns the artifact to the FWS application, which in turn creates a response.
  6. The browser redirects the user with the artifact response to discounts.com.

Discounts.com is the consumer site. The administrator at discounts.com configures an SP-to-IdP partnership. The partnership configuration specifies the location of the assertion retriever service at smcompany.com, and the protected target resources.

The user identification configuration for the partnership must specify a custom user search specification that looks up a single user. For example, if the user directory is LDAP, the search specification is uid=user1.

Important! To map every user to a single user, a user directory at discounts.com must exist. This user directory must contain a single user record. An alternative is to create a user directory using the Policy Server API that returns the same user record.

The following process occurs:

  1. The browser posts the response to the SAML credential collector, which obtains the location of the assertion retrieval service at smcompany.com.
  2. The SAML credential collector makes a back channel call to the Assertion Retrieval Service at smcompany.com. The session ID is extracted from the artifact.
  3. The Policy Server retrieves the assertion from the session store and returns it to the SAML credential collector at discounts.com.
  4. The SAML credential collector then validates the SAML assertion and issues a session cookie to the browser.
  5. The browser redirects the user to the target resource at discounts.com.

Use Case: SAML 2.0 Single Logout

In this use case, an employee of smcompany.com authenticates at the employee portal and selects a link to view the health benefits at ahealthco.com. The employee is taken to the ahealthco.com website and presented with the health benefit information without logging in to the site.

After the employee logs out from ahealthco.com, the site wants to verify the termination of the user session at ahealthco.com and at smcompany.com. Terminating both sessions prevents an unauthorized employee from using the existing session to access resources at smcompany.com or to view benefits of the authorized employee.

Note: In this case, the initial logout occurs at ahealthco.com and results in both sessions being terminated.

The following illustration shows the use case.

Graphic of how a single logout ends the user session at two websites

Solution: SAML 2.0 Single Logout

You can use federation to solve Use Case: SAML 2.0 Single Logout.

In this solution:

The following figure shows the solution for single logout.

Graphic showing the solution for single logout

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the Federation Web Services application functions. For information about installing and configuring the SPS federation gateway, see the Secure Proxy Server Administration Guide.

The following sequence of events for SP-initiated single logout occurs:

  1. An employee authenticates at smcompany.com then accesses health benefits at ahealthcom.com by way of federated single sign-on. Smcompany.com places information about ahealthco.com in its session store. Ahealthco.com places information about smcompany.com in its session store.
  2. The employee finishes reviewing health benefits and clicks a log-out link at ahealthco.com. The browser accesses the single logout servlet.
  3. The FWS application at ahealthco.com renames the existing SMSESSION cookie to SESSIONSIGNOUT to invalidate the current session of the user.
  4. The user session is terminated at the ahealthco.com.

    Note: The termination does not remove the session from the session store; it sets the state to LogoutInProgress.

  5. The Policy Server generates a logout request to invalidate the user session at smcompany.com. The Policy Server also returns the provider ID of smcompany.com.
  6. The browser redirects the log out request to the single logout servlet at smcompany.com, with the logout request message added as a query parameter.
  7. The FWS application receives the log out request message, and renames the SMSESSION cookie to SESSIONSIGNOUT.
  8. FWS invalidates the user session from all Service Providers that are associated with that user session. The only exception is the session at ahealthco.com, who initiated the log out request.
  9. After all the Service Providers confirm the logout, smcompany.com removes the user session from its session store. FWS deletes the SESSIONSIGNOUT cookie.

    Note: Other Service Providers are not identified in the illustration.

  10. Smcompany.com returns a logout response message to ahealthco.com, the initiating Service Provider, and the user session is removed from its session store.
  11. The user is finally sent to the SLO configuration page at ahealthco.com.

Use Case: WS-Federation Sign-out

In this use case, an smcompany.com employee authenticates at the employee portal. The employee selects a link to view health benefits at ahealthco.com. The employee is taken to the ahealthco.com website and presented with the health benefit information without having to sign on to the site.

When the employee logs out, ahealthco.com wants the user session at its site and at smcompany.com terminated. Terminating both sessions prevents an unauthorized person from using the existing sessions to access resources at smcompany.com or ahealthco.com.

The following illustration shows the use case.

usecase_single_logout

Solution: WS-Federation Signout

The following federated deployment solves Use Case: WS-Federation Sign-out.

In this solution:

The following figure illustrates WS-Federation sign-out.

Graphic showing a WS-Federation signout solution

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the Federation Web Services application functions. For information about installing and configuring the SPS federation gateway, see the Secure Proxy Server Administration Guide.

The following sequence of events occurs:

  1. An employee authenticates at smcompany.com and federates to ahealthco.com to access their health benefits. During the transaction, smcompany.com places information about ahealthco.com in its session store. Ahealthco.com places information about smcompany.com in its session store.
  2. The employee finishes viewing his health benefit information, and clicks a log-out link at ahealthco.com. The sign-out service receives a sign-out request.
  3. The sign-out service fetches session information from the SMSESSION cookie and determines the Identity Provider that is associated with the user session.
  4. The sign-out service calls the Policy Server to invalidate the session.
  5. The sign-out service generates a sign-out request, and forwards the sign-out request to the Signout URL at smcompany.com.
  6. The sign-out service at smcompany.com receives the request.
  7. The sign-out service fetches session information from the SMSESSION cookie and determines the Resource Partner that is associated with the user session.
  8. The sign-out service calls the Policy Server to invalidate the session.
  9. The sign-out service generates a sign-out request, and posts a sign-out message and multiple RP-SignoutCleanup locations as post data to the SignoutConfirmURL JSP.

    The SignoutConfirm page generates a frame-based HTML page. Each frame contains a Signout Cleanup URL for each Resource Partner that is associated with the user session.

  10. Ahealthco.com forwards the sign-out request to any Resource Partner associated with the user session. At each RP, the session is terminated from the session store.
  11. Each RP redirects the browser to the Sign-out Cleanup URL ahealthco.com, as the initiating partner to complete the sign-out.

Use Case: Identity Provider Discovery Profile

In this use case, several companies contract health benefits from ahealthco.com. A user logs on to ahealthco.com to view their health benefits. Ahealthco.com must determine which Identity Provider it sends an authentication request to for a particular user.

IdP discovery is useful in federated networks that have more than one partner providing assertions. This profile provides a dynamic way for a Service Provider to determine which Identity Provider has the necessary user record.

The following illustration shows a network with the Identity Provider Discovery profile in use.

Note: A prior business agreement between the sites in this network exists so that all sites interact with the Identity Provider Discovery service.

Graphic showing an IdP discovery use case

In this example, User1 arrives at ahealthco.com. Ahealthco.com determines that User1 came from smcompany.com. Aheathco.com sets a cookie for smcompany.com in the common domain cookie at ahealthco.com. Other companies, such as forwardinc.com is another Identity Provider that uses ahealthco.com as a health provider. When a user from forwardinc.com comes to ahealthco.com, a cookie is set in the common domain cookie also.

Solution: Identity Provider Discovery Profile

Federation can solve Use Case: Identity Provider Discovery Profile.

The IdP Discovery profile (SAML 2.0 only) is implemented using a cookie domain that is common to the two federated partners. A cookie in the agreed upon domain contains the list of IdPs that a user has visited.

Note: The user that the Service Provider wants to authenticate must have visited the Identity Provider and authenticated before arriving at the Service Provider.

In this solution:

The following illustration shows the federated network for this solution.

Graphic showing the solution for IdP Discovery for SSO

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the Federation Web Services application functions. For information about installing and configuring the SPS federation gateway, see the Secure Proxy Server Administration Guide.

The transaction flow is as follows:

  1. User 1 initially logs in and authenticates at smcompany.com. The user then federates to ahealthco.com without having to reauthenticate.

    An agreement exists between smcompany.com and ahealthco.com to use ahealthcoIPD.com as the IPD service.

  2. The FWS application at smcompany.com requests the Identity Provider Discovery Profile (IPD) configuration from the Policy Server, passing its Identity Provider ID.
  3. The Policy Server returns with the IPD configuration, such as IPD Service URL, common domain cookie, and persistence information of the common domain cookie.
  4. The FWS application at smcompany.com redirects the user to the IPD Service URL to set the common domain cookie. The Identity Provider ID of smcompany.com is written to the common domain cookie at the IPD service.
  5. The IPD service redirects the user back to the single sign-on service at smcompany.com. The redirect contains an authentication request.
  6. The FWS application at smcompany.com requests an assertion from the Policy Server. The Policy Server generates the assertion that is based on the partnership configuration it has for ahealthco.com.
  7. The FWS application returns the assertion response back to ahealthco.com.
  8. User 1 is now successfully logged on to ahealthco.com and can look at the health benefits. The user finishes reviewing health benefits and logs out.
  9. In a separate transaction on a different day, User 1 logs in to ahealthco.com directly. User 1 clicks a link to view healthy benefits again. AhealthIPD.com has cookies for all Identity Providers where User 1 has visited. ahealthco.com calls the IPD discovery service to obtain the Identity Provider IDs.
  10. Ahealthco.com presents a site selection page to User 1 to select the company where they can authenticate. User 1 selects smcompany.com.
  11. Ahealthco.com sends an authentication request to smcompany.com. The Policy Server at smcompany.com generates an assertion and sends it back to the Assertion Consumer Service at ahealthco.com.
  12. The user successfully logs in and is redirected to the requested resource.

Use Case: Federation with Multiple SSO Profiles

In this use case, smcompany.com issues assertions for ahealthco.com and discounts.com. Ahealthco.com uses the SAML 2.0 profile. Discounts.com uses the WS-Federation profile. The assertions issued must be generated according to the appropriate profile so that the relying party can consume the assertion.

The following illustration shows the multiprotocol use case.

Graphic of multiprotocol federation use case environment

Solution: Federation with Multiple SSO Profiles

The following federation deployment solves the Use Case: Federation with Multiple SSO Profiles.

Note: The single sign-on transactions in this solution are similar to the using account linking transactions.

In this solution:

User 1

User 2

The following illustration shows a federated network that implements multiprotocol support.

solution_multiprotocol_two

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the Federation Web Services application functions. For information about installing and configuring the SPS federation gateway, see the Secure Proxy Server Administration Guide.

In this multiprotocol solution, the flow of the single sign-on transactions for the various SSO profiles is similar to the account linking SSO transactions.

For this solution, the following partnerships are configured at smcompany.com

The following partnership is configured at ahealthco.com:

The following partnership is configured at discounts.com:

Use Case: SAML 2.0 User Authorization Based on a User Attribute

In this use case, forwardinc.com is a car rental service and exampleair.com is a travel agency.

A customer of forwardinc.com logs in and authenticates at forwardinc.com, then clicks a link at the site to get a quote for a car rental. The customer profile at forwardinc.com includes the customer frequent flyer number for exampleair.com. The frequent flyer account determines a certain status level at forwardinc.com. The status level determines which discount offers the customer receives for car rentals.

The following illustration shows this use case.

Graphic of user authorization based on a user attribute

Forwardinc.com wants to present the appropriate discount information to its customers. However, it does not want customers to log in and authenticate at exampleair.com first then having to log in again at its site.

Solution: SAML 2.0 User Authorization Based on a User Attribute

The SAML 2.0 Attribute Query/Response profile can solve Use Case: SAML 2.0 User Authorization Based on a User Attribute.

Graphic showing an attribute query and response

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the Federation Web Services application functions. For information about installing and configuring the SPS federation gateway, see the Secure Proxy Server Administration Guide.

In this deployment,

Forwardinc.com is acting as a SAML Requester. When a customer logs in at this site, the following sequence of events occurs:

  1. The user logs in to forwardinc.com and authenticates the user.
  2. The user clicks a link to rent a car. Forwardinc.com identifies an unresolved frequent flyer attribute.
  3. Forwardinc.com tries to resolve the attribute by looking up the user in the local user directory, but it cannot resolve the user attribute variable.
  4. Forwardinc.com sends an attribute query as a SOAP request to the IdP/Attribute Authority, exampleair.com. The query request contains the frequent flyer attribute.
  5. Exampleair.com looks at its own user directory record for the user and resolves the frequent flyer attribute. Exampleair.com returns an assertion as a SOAP response to forwardinc.com. The assertion contains the requested attribute.
  6. The SAML Requester resolves the attribute and authorizes the user for the requested resource.
  7. The user is redirected to the target resource.

Use Case: Single Sign-on with No Name ID at the IdP

In this use case, discounts.com purchases widgets from smwidgets.com.

A buyer for discounts.com clicks on a link to access the latest widget price list at smwidgets.com. The buyer is taken to the smwidgets.com website and presented with the price list without having to log in to the discounts.com website.

The following illustration shows this use case.

Graphic showing SSO when there is no User ID at IdP

There are no buyer identities stored locally at discounts.com, so discounts.com wants to obtain an identity for buyers at smwidgets.com. Discounts.com sends an authentication request to smwidgets.com. Smwidgets.com receives the request, but it cannot find a value for the NameID attribute. It generates a unique persistent identity for the buyer and adds this identity to the assertion. Discounts.com uses this unique identifier to allow the buyer access to the requested resource.

Solution: Single Sign-on with No Name ID at the IdP

Use of the Allow/Create attribute solves Use Case: Single Sign-on with No Name ID at the IdP.

NOTE: This solution requires the SAML 2.0 profile.

Federation is deployed at discounts.com and smwidgets.com. A Web Agent and Web Agent Option pack is installed on one system, and the Policy Server is installed on another system.

In the following illustration, smwidgets.com is the Identity Provider and discounts.com is the Service Provider.

Graphic of AllowCreate Attribute Flow

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the Federation Web Services application functions. For information about installing and configuring the SPS federation gateway, see the Secure Proxy Server Administration Guide.

To enable single sign-on between the two sites with no user identity at the Identity Provider, the following sequence of events occurs.

  1. The user, in this case the buyer, authenticates at discounts.com. This link initiates an authentication request.
  2. The Policy Server at discounts.com checks for presence of the Allow/Create option in the configuration. The option is enabled in the SP-to-IdP partnership at the discounts.com.
  3. An attribute named AllowCreate is included in the authentication request. The Federation Web Services application at the local Web Agent redirects the authentication request to smwidgets.com.
  4. The Policy Server at smwidgets.com generates an assertion. During the assertion generation, the Policy Server searches for the NameID attribute in the user record of the user requesting the resource. There is no value for the NameID in the user record.
  5. The Policy Server verifies its configuration for the AllowCreate option. The Policy Server also checks the authentication request for the AllowCreate attribute, which it finds.
  6. The Policy Server generates a unique persistent identifier because of the presence of the AllowCreate attribute in the authentication request and in its own configuration. The Policy Server places the identifier in its user store.
  7. The Policy Server returns the assertion to the Federation Web Services at the application at the discounts.com. The Federation Web Services application sends an auto-post form containing the assertion response to the Assertion Consumer Service at discounts.com.
  8. The Service Provider at discounts.com uses the response message to log in to the Policy Server, using the response as credentials.
  9. The Policy Server validates the response by looking for the NameID in its user store. The Policy Server locates the user and logs in the user.
  10. The Web Agent generates an SMSESSION cookie for the discounts.com domain.
  11. The Web Agent places the cookie in the browser and redirects the user to the target destination.

Use Case: SSO Using Security Zones

In this use case, CompanyA protects non-federated web applications and supports federated single sign-on. In a CA SiteMinder® deployment, you cannot have two sessions for a single user that travels from the web application environment to the federated environment. As the user navigates between each environment, the session cookies would overwrite one another.

The following illustration shows a site that combines a federated environment and a web application environment.

Graphic showing a use case with security zones

Solution: SSO Using Security Zones

This solution illustrates how security zones lets you set up a parallel web application and a federation environment to solve the Use Case: SSO Using Security Zones.

A security zone is a segment of a single cookie domain, which is used to partition applications. You can assign different security requirements to each zone. Security zones lets the Policy Server generate different session cookies for a single user in each environment. Though two uniquely named session cookies are generated, each cookie represents the same session across the web application and federated environments. Web agents at the asserting party enforce security zones.

The following figure illustrates a deployment with two different environments at a single asserting party. One environment is for federation functionality and the other is for web application protection.

Graphic showing a federated solution with security zones (federation)

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the Federation Web Services application functions. For information about installing and configuring the SPS federation gateway, see the Secure Proxy Server Administration Guide.

The figure reflects the following setup:

Web Application Environment

Agent Configuration Object or Local Configuration file

DefaultAgent

Trusted Security Zone

SM (default zone)

Cookies the Web Agent reads for the zone

The DefaultAgent configuration enables the Web Agent to read and write the default session cookie, SMSESSION.

Federation Environment

Agent Configuration Object or Local Configuration file

FedWA

Trusted Security Zones
Cookies the Web Agent reads for the zone

The FedWA configuration enables the Web Agent to read and write SMSESSION cookies.

Note: For this solution to work, each environment must have its own Agent Configuration Object.

The following sequence of events follows:

  1. The user logs in to the federation environment.
  2. The Web Agent in the federated environment directs a request to the Authentication URL to establish a user session.

    The user already has an SMSESSION cookie from a prior authentication in the web application environment.

  3. The Web Agent in the federated environment reads the SMSESSION cookie. The Policy Server generates a new federation session cookie and the Web Agent writes this new session cookie to the browser. The new federation session cookie is based on the SMSESSION cookie.

    Federation requires a persistent session, which is stored in the session store. The SMSESSION cookie that is read from the web application environment is not persistent. When the Policy Server generates a federation cookie, it modifies the cookie and upgrades the session to be a persistent session.

  4. The FWS application in the federated environment reads the federation cookie and successfully processes the request for the resource.

Use Case: SSO with Dynamic Account Linking at the SP

In the use case, the IdP, discounts.com, includes an attribute named buyer ID that identifies a particular user. The buyer ID value is entered as the NameID in the assertion. However, there is no mapped identity at smwidgets.com for the buyer ID. Smwidgets.com must create an attribute in the appropriate user record so that the buyer can authenticate and gain access to the protected resource.

The administrator at the smwidgets.com establishes a mapping using dynamic account linking. The mapping lets smwidgets can authenticate the buyer and can allow access to resources. When a buyer at discounts.com selects a link to access the latest price list on widgets at smwidgets.com, the buyer is logged in without having to reauthenticate.

The following illustration shows this use case.

Graphic of use case for user with no mapped ID

Solution: SSO with Dynamic Account Linking at the SP

Federation can be deployed at IdPA.com and SPB.com to solve Use Case: SSO with Dynamic Account Linking at the SP.

Note: Dynamic account linking is only supported with SAML 2.0.

CA SiteMinder® is deployed at both sites. Each site has a Web Agent and Web Agent Option Pack installed on one system, and the Policy Server on another system.

The following illustration shows single sign-on with dynamic account linking at the Service Provider.

Graphic showing Dynamic Account Linking at SP

Note: The SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the Federation Web Services application functions. For information about installing and configuring the SPS federation gateway, see the Secure Proxy Server Administration Guide.

The following sequence of events occurs:

  1. The employee initially logs in and authenticates at discounts.com. Discounts.com creates an assertion for the employee. Discounts.com posts the assertion (POST binding) or redirects the user with an artifact (artifact binding) to the Assertion Consumer Service at smwidgets.com. This assertion includes an attribute named buyerID.
  2. The Assertion Consumer Service at smwidgets.com tries to authenticate the user, but the buyerID attribute does not map to a local user record. The authentication fails.
  3. As part of the partnership configuration at smwidgets.com, a redirect URL is defined, which points to the directory web_agent_home/affwebservices/linkaccount.jsp. The employee is redirected to this URL.

    Note: The linkaccount.jsp file must be part of a protected realm. The default location for this file is http://sp_home/affwebservices/public/. Copy the file from this location to a protected realm.

  4. A Web Agent that authenticates the local user with the forms authentication scheme protects this linkaccount.jsp URL. After a successful authentication, a session at smwidgets.com is established and an SMSESSION cookie is placed in the employee's browser.
  5. The linkacount.jsp gets loaded in the browser and the user sees a message to link to the Service Provider account. Click on the button to permit the account linking.
  6. The user is redirected to the Assertion Consumer Service, where the browser of the employee presents the SMSESSION cookie with the assertion.
  7. The Assertion Consumer Service extracts the NameID from the assertion and inserts the NameID value into a newly created buyerID attribute. The buyerID attribute is in the existing user record of the employee. The Assertion Consumer Service knows which user record to map because the UserDN in the SMSESSION cookie identifies the user.

    The search specification configured in the SAML 2.0 partnership indicates which attribute is mapped to the NameID. In this case, the search specification is buyerID=%s.

  8. After the attribute is mapped, the user is authenticated based on the assertion. A new user session is established.

    The next time that the same user presents an assertion with the buyer ID, the user successfully gains access to the requested resource.

Configure Dynamic Account Linking at the SP

Configure the following components at the Service Provider to enable dynamic account linking.

Note: Dynamic account linking is only supported with SAML 2.0.

Enable dynamic account linking for SAML 2.0 POST or Artifact single sign-on at the Service Provider

Follow these steps:

  1. For the linkaccount.jsp file, do the following:
  2. Enable the Allow/Create feature at the Service Provider.
  3. For the Web Agent at the Service Provider, set the POST Preservation parameter to yes. This setting enables the POST data from the SAML response to be preserved.
  4. Configure a redirect URL that sends the user to the linkaccount.jsp file if authentication fails. Direct the user only to this file.

    The redirect URL is part of the SAML 2.0 authentication scheme setup at the Service Provider.

    Complete the following fields with the values shown:

    Redirect URL for the User Not Found Status

    http://sp_home/protected_realm/linkaccount.jsp

    Example: http://smwidgets.com/partner_resources/linkaccount.jsp

    The default location of the linkaccount.jsp file is http://sp_home/affwebservices/public/. Copy the file from this directory to a directory that is configured as a protected realm.

    Mode

    HTTP POST

  5. Configure a search specification for the SAML authentication scheme. For example, if the Name ID from the assertion replaces buyerID, the search specification would be buyerID=%s.

More information:

Locate User Records for Authentication

Permit the Creation of a Name Identifier for SSO