This section contains the following topics:
Terminology for Partners in a Federation
Components for Legacy Federation
Legacy Federation Authentication Schemes
Federated Single Sign-on with Security Zones
Secure Proxy Server Federation Gateway
Internationalization in Legacy Federation
Legacy Federation Configuration Flow Chart
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).
Legacy federation is based on configuring CA SiteMinder® objects, such as affiliate domains, affiliate partners, authentication schemes, and policies to protect federated resources.
For more information about CA SiteMinder® federation offerings, legacy federation use cases, and process flow diagrams, see Federation in Your Enterprise.
Legacy federation uses several components:
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 assertion generator stores the assertion in the CA SiteMinder® session store. A reference to the assertion is returned to the Web Agent in the form of a SAML artifact.
CA SiteMinder® returns the assertion by way of a browser as a SAML response embedded in an HTTP form.
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 CA 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.
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.
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:
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 supports the following authentication schemes:
Each authentication scheme enables CA 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.
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 CA 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 CA SiteMinder® SAML Affiliate Agent Guide.
A CA 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 CA 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:
For SAML 1.x and SAML 2.0, the SAML assertion is stored in a persistent session that the relying party retrieves later.
(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:
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.
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.
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 CA SiteMinder®.
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
Legacy federation components log specific events to monitor and debug activity across the federated network.
Displays information about any request to generate a SAML assertion at a producer site.
Displays information about requests to retrieve SAML assertions and to consume SAML assertions.
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.
Displays FWS trace messages that you configure using the FWSTrace.conf file or using one of the provided trace template files.
The following APIs provide support for legacy federation.
The C and Perl Policy Management APIs provide new language elements in support of CA SiteMinder® federation. These new language elements include:
For more information about the Policy Management API, see the CA SiteMinder® Programming Guide for Perl or the CA SiteMinder® Programming Guide for C.
The CA 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 CA SiteMinder® to further process and manipulate a SAML assertion response or the WS-Federation security token response.
For more information, see the CA SiteMinder® Programming Guide for Java.
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 CA SiteMinder® Programming Guide for Java.
The following flow chart highlights the general process for configuring legacy federation.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|