Administration Guide › Administrating CA SiteMinder® SPS › Using CA SiteMinder® SPS with Federation Security Services

Using CA SiteMinder® SPS with Federation Security Services

SiteMinder Federation Security Services (FSS) allow the exchange of security information between business partners. The services provide seamless authentication and fine-grained authorization across enterprises.

Federation Security Services are implemented with CA SiteMinder® SPS in the following ways:

• As a replacement for a SiteMinder Web Agent.
• As a replacement for the SiteMinder Web Agent and the Web Agent Option Pack.

Federation services enable an organization and its partners to:

• Exchange user information in a secure manner
• Map user identities at one organization to user identities at other organizations
• Provide single sign-on across different organizations
• Control access to resources based on user information received from a partner
• Interoperate across heterogeneous environments, such as Windows, UNIX and various Web servers, such as IIS, Sun Java System and Apache

CA SiteMinder® SPS Use Cases in a SiteMinder Federated Environment

There are probably as many use cases for federated networks as there are business arrangements between partners. The use cases that follow demonstrate different ways of handling user identities to provide single sign-on between partners.

For more use cases, see the CA SiteMinder Federation Security Services Guide.

Use Case 1: Single Sign-on Based on Account Linking

In Use Case 1, smcompany.com contracts with a partner company, ahealthco.com to manage employee health benefits.

An employee of smcompany.com authenticates at an employee portal at his company’s site, www.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 her health benefit information without having to sign on to the website.

The following illustration shows this use case.

The company, ahealthco.com, maintains all health-related information for employees at smcompany.com. To do this, ahealthco.com maintains user identities for every employee of 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.

More information:

Solution 1: SSO Based on Account Linking

Use Case 2: Single Sign-on Based on User Attribute Profiles

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

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

When 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.

Additional 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 employees at smcompany.com, but the company wants to control access to sensitive portions of the website. To control the access, partsco.com maintains a limited number of profile identities for users at smcompany.com. One profile identity is maintained for engineers and one profile 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 what profile identity controls access.

More information:

Solution 2: SSO Using User Attribute Profiles

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

In Use Case 3, smcompany.com offers employee discounts by establishing a partnership with discounts.com.

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

The following illustration shows this use case.

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 long as they have been authenticated at smcompany.com. When an employee of smcompany.com accesses discounts.com, authentication information is sent in a secure manner from smcompany.com to discounts.com. This information is used to allow access to discounts.com.

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

More information:

Solution 3: SSO with No Local User Account

Use Case 4: Extended Networks

In Use Case 4, smcompany.com, ahealthco.com, and discounts.com all participate in an extended federated network. This case is an extension of the previous use cases.

In this network, not all customers of ahealthco.com work at smcompany.com. Ahealthco.com provides discounts only to its customers by establishing a relationship between themselves and discounts.com. Ahealthco.com maintains user identities for every customer so ahealthco.com manages local credentials, such as a password for each user. By managing local credentials, ahealthco.com can authenticate users and can provide single sign-on access to its partners.

In this extended network, the users access each website differently:

• User1 accesses health benefit information at the ahealthco.com website. User1 can access the partsco.com website by clicking the PartsSupplier link at smcompany.com, the employee portal. User1 can also click a link at the employee portal to access discounts at discounts.com.

  User2 authenticates at the ahealthco.com website and clicks a link to access discounts at discounts.com, without logging in to the discounts.com website. The discounts the site presents to User2 reflect the business arrangement between ahealthco.com and discounts.com. Being employee of smcompany.com, User2 can also click a link at ahealthco.com and access the employee portal at smcompany.com without logging in to website.

• User3 (not shown in the example), is a customer of ahealthco.com, but is not an employee of smcompany.com. User3 authenticates at the ahealthco.com website and clicks a link to access discounts at discounts.com. User3 does not log in to the website. The discounts the site presents to User3 reflect the business arrangement between ahealthco.com and discounts.com. Because User3 is not an employee of smcompany.com, User3 cannot access the smcompany.com website.

More information:

Solution 4: SSO in an Extended Network

CA SiteMinder® SPS Roles in a SiteMinder Federated Environment

CA SiteMinder® SPS can provide solutions to federation use cases in one of two roles:

• As a standard proxy server that replaces the SiteMinder Web Agent
• As a federation gateway

The primary distinction between these two roles is the configuration and deployment effort required. The proxy server that replaces the Web Agent still requires that you set up a separate server and servlet engine to run the Federation Web Services application.

The proxy server acting as a federation gateway has the components of the Web Agent and the Federation Web Services application built-in. A dedicated server and servlet engine are not configured separately, which simplifies the federation setup.

Solutions for CA SiteMinder® SPS Use Cases

The following sections show CA SiteMinder® SPS solutions to the federation use cases.

Solution 1: SSO Based on Account Linking

Solution 1 illustrates how Federation Security Services can be deployed at smcompany.com and ahealthco.com to solve Use Case 1: Single Sign-on Based on Account Linking.

The following figure shows the solution based on account linking.

CA SiteMinder® is deployed at both sites and the installations are the same for both smcompany.com and ahealthco.com. CA SiteMinder® SPS with the Web Agent Option Pack or CA SiteMinder® SPS federation gateway can be installed on the Web server system and the Policy Server with the Policy Server Option Pack are installed on another machine.

The FWS application at the producing side provides the service that retrieves assertions. The FWS application at the consuming side provides the service that consumes assertions.

Using SAML 1.x Artifact Authentication for Solution 1

The process that follows is one solution for single sign-on with account linking. This solution uses the SAML 1.x artifact profile. There are other solutions for this use case that involve other profiles (SAML 1.x POST and SAML 2.0 Artifact and POST). For these solutions, see the CA SiteMinder Federation Security Services Guide.

In this solution, smcompany.com is acting as the producer site. When an employee of smcompany.com accesses an employee portal at www.smcompany.com, the sequence of events is as follows:

1. CA SiteMinder® SPS provides the initial authentication.
2. When the employee clicks a link at smcompany.com to view her health benefits at ahealthco.com, the link makes a request to the Intersite Transfer Service at www.smcompany.com.
3. The Intersite Transfer Service calls the assertion generator, which creates a SAML assertion, inserts the assertion into the SiteMinder session server, and returns a SAML artifact.
4. CA SiteMinder® SPS redirects the user to www.ahealthco.com with the SAML artifact, in accordance with the SAML browser artifact protocol.

Ahealthco.com is acting as the consumer site. The redirect request with the SAML artifact is handled by the SAML credential collector Federation Web Services at ahealthco.com.

The sequence of events is as follows:

1. The SAML credential collector calls the SAML artifact authentication scheme to obtain the location of the assertion retrieval service at smcompany.com.
2. The SAML credential collector calls the assertion retrieval service at www.smcompany.com.
3. The assertion retrieval service at www.smcompany.com retrieves the assertion from the SiteMinder session server and returns it to the SAML credential collector at ahealthco.com.
4. The SAML credential collector then passes the assertion to the SAML artifact authentication scheme for validation and session creation and proceeds to issue a SiteMinder session cookie to the user’s browser.
5. At this point the user is allowed access to resources at ahealthco.com based on policies defined at the Policy Server at ahealthco.com and enforced by CA SiteMinder® SPS at ahealthco.com.

In this example, the administrator at smcompany.com uses the Policy Server User Interface to configure an affiliate for ahealthco.com. The affiliate is configured with an attribute that is a unique ID for the user. This causes the assertion generator to include that attribute as part of the user profile in a SAML assertion created for ahealthco.com.

The administrator at ahealthco.com uses the Policy Server User Interface to configure a SAML artifact authentication scheme for smcompany.com. The authentication scheme specifies the location of the assertion retriever service at smcompany.com, how to extract the unique user ID from the SAML assertion, and how to search the user directory at ahealthco.com for the user record that matches the value extracted from the assertion.

Solution 2: SSO Using User Attribute Profiles

Solution 2 shows how SiteMinder Federation Security Services can be deployed at smcompany.com and partsco.com to solve Use Case 2: Single Sign-on Based on User Attribute Profiles.

CA SiteMinder® is deployed at both sites. The interactions between the user and each site is similar, where partsco.com is acting as the consuming authority. The FWS application at the producing side provides the service that retrieves assertions. The FWS application at the consuming side provides the service that consumes assertions.

The following illustration is similar for SAML 1.x, SAML 2.0, and WS-Federation; however, the Federation Web Services components are different as follows:

• For SAML 1.x, the Assertion Retrieval Service (for artifact profile only) is at the Producer and the SAML credential collector is at the SP.
• For SAML 2.0, the Artifact Resolution Service (for artifact binding only) is at the IdP and the Assertion Consumer Service at the SP.
• For WS-Federation, the Single Sign-on Service is at the AP and the Security Token Consumer Service is at the RP.

  Note: WS-Federation only supports HTTP-POST binding.

The configuration is similar to Solution 1: Single Sign-on based on Account Linking, except for the following:

• The administrator at smcompany.com defines the consumer/SP for partsco.com with an attribute specifying the user’s department at the company. The assertion generator will include this attribute as part of the user profile in the SAML assertion created for partsco.com.
• The administrator at partsco.com defines an authentication scheme (artifact, post, or WS-federation) for smcompany.com. The scheme extracts the department attribute from the SAML assertion and searches the user directory at partsco.com for the user record that matches the department value taken from the assertion. The administrator defines one user profile record for each department that is allowed to access partsco.com's web site.

Solution 3: SSO with No Local User Account

Solution 3 shows how SiteMinder Federation Security Services can be deployed at smcompany.com and discounts.com to solve Use Case 3: Single Sign-on with No Local User Account.

CA SiteMinder® is deployed at smcompany.com by installing CA SiteMinder® SPS on one machine, the Web Agent Option Pack on another machine and installing the Policy Server with the Policy Server Option Pack on a third machine. The SAML Affiliate Agent is installed at discounts.com. It only supports SAML 1.0.

The FWS application at the producing side provides the assertion retrieval service. The FWS application at the consumer side provides the SAML credential collector.

Note: CA SiteMinder® SPS federation gateway does not support SAML 1.0 and therefore cannot act as a producer for the SAML Affiliate Agent.

The following figure shows single sign-on with no local user account.

Smcompany.com is acting as a SAML 1.x producer. When an employee of smcompany.com accesses an employee portal at www.smcompany.com, the following occurs:

1. CA SiteMinder® SPS provides the initial authentication.
2. When the employee clicks a link at www.smcompany.com to access deals at discounts.com, the link makes a request to CA SiteMinder® SPS at www.smcompany.com.
3. CA SiteMinder® SPS at www.smcompany.com calls the assertion generator, which creates a SAML assertion, inserts the assertion into the SiteMinder session server, and returns a SAML artifact.
4. CA SiteMinder® SPS redirects the user to www.discounts.com with the SAML artifact in accordance with the SAML browser artifact protocol.

Discounts.com is acting as the consumer site. The redirect request with the SAML artifact is handled by the SAML Affiliate Agent at www.discounts.com, as follows:

1. The SAML Affiliate Agent obtains the location of the assertion retrieval service at www.smcompany.com from a configuration file.
2. The SAML Affiliate Agent calls the assertion retrieval service at www.smcompany.com.
3. The assertion retrieval service at www.smcompany.com retrieves the assertion from the SiteMinder session server and returns it to the SAML affiliate agent at www.discounts.com.
4. The SAML Affiliate Agent then validates the SAML assertion and issues a SiteMinder affiliate session cookie to the user’s browser.
5. The user is allowed access to resources at discounts.com.

The administrator at smcompany.com uses the Policy Server User Interface to configure an affiliate for discounts.com. The affiliate is configured with attribute information to be passed to discounts.com. The assertion generator will include those attributes as part of the user profile in a SAML assertion created for discounts.com.

The administrator at discounts.com configures the SAML Affiliate Agent with information about the discounts.com site, the location of the assertion retriever service at smcompany.com, and what resources are to be protected by the affiliate defined at smcompany.com.

Solution 4: SSO in an Extended Network

Solution 4 illustrates how SiteMinder Federation Security Services can be deployed at smcompany.com, ahealthco.com, and discounts.com to solve Use Case 4: Extended Networks.

The following illustration shows an extended network. SAML 1.x is the protocol being used.

SiteMinder is deployed at smcompany.com and ahealthco.com. At smcompany.com, CA SiteMinder® SPS with the Web Agent Option Pack can be installed across two machines or CA SiteMinder® SPS federation gateway can be installed on one machine. The Policy Server with the Policy Server Option Pack is installed on another machine. At ahealthco.com, CA SiteMinder® SPS with the Web Agent Option Pack can be installed across two machines and the Policy Server with the Policy Server Option Pack is installed on another machine. At discounts.com, the SAML Affiliate Agent is installed.

The FWS application at the producing side provides the service that retrieves assertions. The FWS application at the consuming side provides the service that consumes assertions.

In Solution 4:

• smcompany.com acts as a producer for User1 and a consumer for User2
• ahealthco.com acts as a consumer for User1 and a producer for User2 and a producer for User3
• discounts.com acts as a consumer for User1, User2, and User3

The administrator for smcompany.com has configured two entities in an affiliate domain, which represents ahealthco.com and discounts.com. These sites are configured in a similar manner as in Examples 1 and 3 described previously, but the configurations have been extended as follows:

• At smcompany.com, the administrator has configured a SAML authentication scheme (artifact or POST). For User2, the authentication scheme enables smcompany.com to act as a consumer for ahealthco.com.
• At ahealthco.com:
  • The administrator has configured an affiliate object that represents smcompany.com so an assertion is produced for User2. This makes single sign-on to smcompany.com possible.
  • The administrator has configured an affiliate object that represents discounts.com so an assertion is produced for User2 and User3. This makes single sign-on to discounts.com possible.
• At discounts.com, the administrator has configured the SAML Affiliate Agent to act as a consumer for smcompany.com, as in Example 3 (an arrow connecting the two sites is not shown in the illustration). The administrator at discounts.com has also added configuration information about ahealthco.com so that the SAML Affiliate Agent can consume assertions from ahealthco.com for User2 and User3.

Using CA SiteMinder® SPS in Cookieless Federation

Certain devices or environments cannot use cookies to establish user session and provide single sign-on.

One type of session scheme you can use in a federated environment is a cookieless scheme. The cookieless federation scheme is used to establish single sign-on. Verify that FWS-generated cookies (session and attribute) are not sent back to clients using mobile devices that do not support cookies.

Cookieless Federation at the Producing Site

At the site producing assertions, the process for a cookieless transaction is as follows:

1. CA SiteMinder® SPS verifies if cookieless federation is enabled for the virtual host requesting the redirect.
2. CA SiteMinder® SPS verifies if the session scheme is a rewritable scheme, such as the simple_url scheme.
3. If the scheme is rewritable, CA SiteMinder® SPS determines whether a session key has been created for the session and if this key is available to use.
4. CA SiteMinder® SPS checks to see if the Location header in the HTTP response meets one of the following conditions:
   • It is being rewritten.
   • It is the same as the host of the request.
5. CA SiteMinder® SPS rewrites the redirect response to include the session key information in the redirected URL.

Cookieless Federation at the Consuming Site

At the site consuming assertions, if cookieless federation is enabled, CA SiteMinder® SPS replacing the Web Agent processes redirects using SAML authentication at the backend server.

In a cookieless federation, CA SiteMinder® SPS processes the request as follows:

1. CA SiteMinder® SPS receives a request from cookieless device, such as a mobile phone.
2. CA SiteMinder® SPS verifies if the cookieless federation is enabled for the virtual host requesting the redirect.
3. CA SiteMinder® SPS then checks to see if the following conditions have been met:
   • The response from the backend server is a redirect.
   • The response contains an SMSESSION cookie.

   If these two conditions are met at the same time, it indicates that a SAML authentication has occurred at the backend server from the FWS application.

4. CA SiteMinder® SPS retrieves the session scheme being used.
5. CA SiteMinder® SPS creates an associated cookieless session and adds the session information to its session store.
6. If the session scheme is rewritable, such as a simple URL session scheme, CA SiteMinder® SPS rewrites the location header with the session key.
7. If CA SiteMinder® SPS determines that a cookieless federated session conversion has occurred, CA SiteMinder® SPS deletes the SMSESSION cookie from the response going to the browser.
8. CA SiteMinder® SPS then checks to see if attribute cookies should also be deleted. It does this by checking the deleteallcookiesforfed parameter. If this parameter is set to yes, CA SiteMinder® SPS deletes all the other cookies from the response going to the browser.

Enable Cookieless Federation at the Consuming Side

When CA SiteMinder® SPS replaces the Web Agent at the side consuming assertions, the cookieless federation parameters are enabled for any cookieless session scheme implemented by CA SiteMinder® SPS.

To enable cookieless federation for CA SiteMinder® SPS at the consuming side

1. Open noodle.properties file from sps_home/secure-proxy/Tomcat/properties.
2. Remove the '#' from the following two lines, and save the file.
   • filter._cookielessfederation_.class=org.tigris.noodle.filters.CookielessFedFilter
   • filter._cookielessfederation_.order=1

   The settings are saved.

3. Open the server.conf file located at sps_home/secure-proxy/proxy-engine/conf.
4. Add the following code to the virtual host section for the virtual host that is serving the FWS:

   cookielessfederation="yes"

5. Save the file.

   CA SiteMinder® SPS is configured for cookieless federation at the consuming partner.