Previous Topic: Legacy Federation GuideNext Topic: Deploy Legacy Federation Using the Sample Application


Legacy Federation Introduction

This section contains the following topics:

Terminology for Partners in a Federation

Components for Legacy Federation

Legacy Federation Authentication Schemes

SAML Affiliate Agent

Federated Single Sign-on with Security Zones

Secure Proxy Server Federation Gateway

Internationalization in Legacy Federation

Debugging Features

APIs for Legacy Federation

Legacy Federation Configuration Flow Chart

Terminology for Partners in a Federation

This guide uses the terms asserting party and relying party to identify sides of a federated relationship.

The party that generates assertions is referred to as the asserting party. The asserting party can be:

The party that consumes assertions for authentication purposes is referred to as the relying party. The relying party can be:

A site can be act as an asserting party (producer/IdP/AP) and a relying party (consumer/SP/RP).

Components for Legacy Federation

Legacy federation is based on configuring SiteMinder objects, such as affiliate domains, affiliate partners, authentication schemes, and policies to protect federated resources.

For more information about SiteMinder federation offerings, legacy federation use cases, and process flow diagrams, see Federation in Your Enterprise.

Legacy federation uses several components:

SAML Assertion Generator

A Policy Server component that creates SAML assertions at the asserting party.

The SAML assertion generator creates an assertion for a user who has a session at a producer/IdP site. When a partner requests a SAML assertion, the Web Agent invokes the SAML assertion generator. The assertion generator creates an assertion that is based on a user session and information in the policy store.

The assertion generator processes the assertion according to the authentication profile or binding configured, as follows:

The Web Agent is responsible for sending the SAML artifact, SAML response, or WS-Federation security token response to the relying party in accordance with the SAML profile. At the relying party, a client must be available to process the SAML artifact or response message. If SiteMinder is the relying party, the client can be the SAML 1.x credential collector or the SAML 2.0 assertion consumer.

You can customize the content of a SAML assertion by configuring the assertion generator plug-in. This plug-in lets you customize the content for your federated environment.

WS-Federation Assertion Generator

A Policy Server component that creates WS-Federation RequestSecurityTokenResponse messages containing SAML assertions.

The WS-Federation assertion generator creates a SAML 1.1 assertion for a user who has a session at an Account Partner. When a user requests a resource, the Web Agent invokes the WS-Federation assertion generator at the Policy Server. The Policy Server creates an assertion that is based on the user session and information configured in the policy store. The assertion generator then places the assertion in a WS-Federation RequestSecurityTokenResponse message.

The Web Agent sends the security token response message, through a browser, to the relying party in accordance with the WS-Federation Passive Requestor profile. At the Resource Partner, a client, such as WS-Federation Assertion Consumer must be available to process the assertion.

You can customize the content of the SAML assertion by configuring the assertion generator plug-in. This plug-in lets you customize the content for your federated environment.

Federation Authentication Schemes

A Policy Server component that validates SAML or WS-Federation assertions and maps assertion data to a local user at the relying party.

The supported authentication schemes are:

Federation Web Services

A Web Agent component that supports assertion retrieval, session synchronization and notification alerts at the asserting party. At the relying party, these services collect assertions.

Legacy Federation Authentication Schemes

Legacy federation supports the following authentication schemes:

Each authentication scheme enables SiteMinder at the relying party to process SAML assertions. Upon receiving an assertion, the authentication scheme

The SAML authentication scheme is where you map remote users at the asserting party to local users at the relying party. User mapping enables the authentication scheme to locate the correct user record for authentication.

SAML Affiliate Agent

The SAML Affiliate Agent enables businesses using the Policy Server and Web Agent to act as a main portal and share security and customer profile information with affiliated partners. The affiliated partners use only the SAML Affiliate Agent.

Note: The SAML Affiliate Agent only supports SAML 1.0 and it is not FIPS-compatible.

The SAML Affiliate Agent is a stand-alone component. This agent provides single sign-on and session management capabilities to a third-party consumer. The consumer, or affiliate, does not maintain identities for users at the producer, or portal, site. The affiliate site can determine that the user has been registered at the portal site, and optionally, that the user has an active SiteMinder session at the portal site. Based on the affiliate policies at the portal, information can be passed to the affiliate and set as cookies or header variables for the affiliate web server.

For more information about the SAML Affiliate Agent, see the SiteMinder SAML Affiliate Agent Guide.

Federated Single Sign-on with Security Zones

A SiteMinder environment can be set up to include a web application environment for web service protection and a federation environment for federated resource protection. This method can make a SiteMinder deployment more efficient.

Certain federation features require a persistent user session, which means that the SAML assertion is stored in the session store of the Policy Server.

These features include:

Artifact Single sign-on

For SAML 1.x and SAML 2.0, the SAML assertion is stored in a persistent session that the relying party retrieves later.

Single Logout

(SAML 2.0 Single Logout and WS-Fed Signout) at producer and consumer sites. Partner data is stored in a persistent user session to facilitate notification of partners during a federated logout.

Use of persistent user sessions slow down performance because of the required calls to the session store to retrieve assertions or handle log-out requests. To limit the performance impact, use security zones.

A security zone is a segment of a single cookie domain. The security zone lets you partition applications to permit different security requirements for resource access. All applications in a single zone permit single sign-on to one another. If an application is in another zone, the trust relationship that you configure determines single sign-on.

For federated applications at the asserting party, implement the following setup:

The use of different zones confines calls to the session server for only federated applications.

Note: In a federated environment, you can only configure Web Agents to use security zones. Secure Proxy Agents and Application Server Agents do not support this feature.

To configure security zones, enter values for the following Web Agent parameters:

SSOZoneName

Identifies a single sign-on security zone. The zone name is added to the cookie domain name to associate the zone with the domain.

Note: This item supports only English-language characters. Characters from other languages are not supported.

SSOTrustedZone

Displays an ordered list of trusted security zones. Defining zones and trusted zone lists determine the cookies that the Web Agent is able to read and write.

These parameters are part of an Agent Configuration Object or a local Agent configuration file.

For more information about security zones, see the Web Agent Configuration Guide.

Secure Proxy Server Federation Gateway

The CA SiteMinder® SPS federation gateway offers a proxy-based solution to access control in a federated network. A traditional proxy typically serves a group of users requesting internet resources. The SPS federation gateway is a reverse proxy, meaning it acts on behalf of users requesting resources from an enterprise.

The SPS federation gateway is a self-contained system. The gateway has its own servlet engine and web server built-in. The SPS gateway relies on its proxy engine to handle requests from federated partners to protected resources. Enhancing SPS to work as a federation gateway allows quick deployments.

As a component of legacy federation, the SPS federation gateway can replace the Web Agent and Web Agent Option Pack to provide the services of the Federation Web Services application. A single SPS federation gateway can limit the amount of configuration that is required for access to resources by limiting the need for many Web Agents.

Note: CA SiteMinder® SPS is a separately licensed product from SiteMinder.

More information:

Federation Web Services

Internationalization in Legacy Federation

Legacy federation supports the following features for I18N internationalization:

If assertions contain multibyte characters, set the LANG setting of your operating system to the following UTF-8 format:

LANG=xx_xx.UTF-8

For example, for Japanese, the entry would be:

LANG=ja_JP.UTF-8

Debugging Features

Legacy federation components log specific events to monitor and debug activity across the federated network.

Web Agent log

Displays information about any request to generate a SAML assertion at a producer site.

Federation Web Services log

Displays information about requests to retrieve SAML assertions and to consume SAML assertions.

Policy Server log

Displays the results of calls from the SAML assertion generator and SAML artifact authentication scheme. Also displays Policy Server trace messages that you configure using the Policy Server Management Profiler or using one of the provided profiler template files.

Web Agent Option Pack logs

Displays FWS trace messages that you configure using the FWSTrace.conf file or using one of the provided trace template files.

APIs for Legacy Federation

The following APIs provide support for legacy federation.

Policy Management API

The C and Perl Policy Management APIs provide new language elements in support of SiteMinder federation. These new language elements include:

For more information about the Policy Management API, see the SiteMinder Programming Guide for Perl or the SiteMinder Programming Guide for C.

Java Message Consumer Plugin API

The SiteMinder Java MessageConsumerPlugin API implements the SAML 1.x, SAML 2.0 and WS-Federation Message Consumer Extension interface. This API allows you to perform your own processing for user disambiguation and authentication. After you customize code for your own requirements, integrate the custom plug-in into SiteMinder to further process and manipulate a SAML assertion response or the WS-Federation security token response.

For more information, see the SiteMinder Programming Guide for Java.

Java Assertion Generator Plugin API

The SiteMinder Java Assertion Generator Plugin API implements the Assertion Generator Framework. Using the plug-in, you can modify the assertion content for your business agreements between partners and vendors.

For more information, see the SiteMinder Programming Guide for Java.

Legacy Federation Configuration Flow Chart

The following flow chart highlights the general process for configuring legacy federation.

Flow diagram showing legacy federation configuration tasks