This section contains the following topics:
Prerequisites for a Relying Partner
How to Configure a Resource Partner
WS-Federation Authentication Scheme Overview
Select the WS-Federation Authentication Scheme Type
Specify the General Information for the WS-Fed Auth Scheme
Locate User Records for Authentication
Configure WS-Federation Single Sign-on at the Resource Partner
Implement WS-Federation Signout
Create a Custom WS-Federation Authentication Scheme
Customize Assertion Processing with the Message Consumer Plug-in
Redirect Users After Failed WS-Federation Authentication Attempts
Supply SAML Attributes as HTTP Headers
How To Protect a Target Resource with a WS-Federation Authentication Scheme
For CA SiteMinder® to act as the relying partner, complete following tasks:
For more information, see the Web Agent Option Pack Guide.
Configuring a WS-Federation Resource Partner requires the following tasks:
Configure a SAML authentication scheme for each Account Partner that is a federation partner and generates assertions. Bind each scheme to a realm, which includes the URLs of the target resources that users request. You can do this task on a per Account Partner basis or can create a single custom authentication scheme and single realm. Protect these resources with a CA SiteMinder® policy.
Tips:
The optional tasks for configuring a Resource Partner include:
The Administrative UI provides two ways to navigate to the legacy federation configuration dialogs.
You can navigate in one of two ways:
When you create an object, a page displays with a configuration wizard. Follow the steps in the configuration wizard to create the object.
When you modify an existing object, a page displays with a series of tabs. Modify the configuration from these tabs. These tabs are the same as the steps in the configuration wizard.
Any CA SiteMinder® site, or SPS Federation Gateway, can consume a <RequestSecurityTokenResponse> message and can use the assertion in the response to authenticate and authorize users. If sites in your federated network have user stores, you can use WS-Federation authentication.
The WS-Federation authentication scheme lets a Resource Partner authenticate a user. The authentication scheme enables cross-domain single sign-on by consuming a SAML assertion and establishing a CA SiteMinder® session. After the user is identified, the Resource Partner site can authorize the user for specific resources.
A site can be both a WS-Federation Resource Partner and Account Partner.
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 WS-Federation authentication scheme is configured at the Resource Partner-side Policy Server. The WS-Federation Security Token Consumer Service invokes the authentication scheme. The Security Token Consumer Service is a component of the Federation Web Services application and is installed on the Resource Partner-side Web Agent. This service obtains information from the WS-Federation authentication scheme at the Policy Server. FWS uses that information to extract the necessary information from the assertion to authenticate a user.
The SAML assertion becomes the user credentials to log in to the Policy Server at the Resource Partner site. The user is authenticated and authorized, and if authorization is successful, the user is redirected to the target resource.
The WS-Federation authentication scheme provides information about the Account Partner that generates the assertion for the Resource Partner. The authentication scheme specifies how the Resource Partner supports the authentication process.
After you configure an authentication scheme, associate the scheme with a realm that contains the resource you want to protect.
To configure a WS-Federation authentication scheme
The Create Authentication Scheme dialog opens.
The contents of the Authentication Scheme dialog change for the scheme.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
After you select the authentication scheme template, you can configure the details of the authentication scheme. You access the rest of the configuration dialogs by clicking WS-Federation Configuration.
Identity the Resource Partner and the Account Partner in the General settings for the WS-Federation authentication schemes.
Follow these steps:
If you are modifying an existing scheme, click Modify then WS-Federation Configuration.
The detailed settings for the scheme display.
Important! For debugging purposes only, you can temporarily disable all signature processing (both signing and verification of signatures) by enabling the Disable Signature Processing option.
The general configuration is complete.
When you configure an authentication scheme, you define a way for the authentication scheme to look up a user in the local user store. After the correct user is located, the system generates a session for that user. Locating the user in the user store is the process of disambiguation. How CA SiteMinder® disambiguates a user depends on the configuration of the authentication scheme.
For successful disambiguation, the authentication scheme first determines a LoginID from the assertion. By default, the LoginID is extracted from the Name ID value in the assertion. You can also obtain the LoginID by specifying an Xpath query.
After the authentication scheme determines the LoginID, CA SiteMinder® checks if a search specification is configured for the authentication scheme. If no search specification is defined for the authentication scheme, the LoginID is passed to the Policy Server. The Policy Server uses the LoginID together with the user store search specification to locate the user. For example, imagine that the LoginID value is Username and the LDAP search specification is set to the uid attribute. The Policy Server uses the uid value (Username=uid) to search for the user.
If a search specification is configured for the authentication scheme, the LoginID is not passed to the Policy Server. Instead, the search specification is used to locate a user.
The disambiguation process involves two steps:
Note: The use of Xpath and the search specification are optional.
You can find the LoginID in two ways:
To specify an Xpath query
The SAML Profiles dialog opens.
Xpath queries must not contain namespace prefixes. The following example is an invalid Xpath query:
/saml:Response/saml:Assertion/saml:AuthenticationStatement/ saml:Subject/saml:NameIdentifier/text()
The valid Xpath query is:
//Response/Assertion/AuthenticationStatement/Subject/
NameIdentifier/text()
You can use a search specification to locate the user in place of the default behavior, where the LoginID is passed to the Policy Server.
To locate a user with a search specification
The SAML Profiles dialog opens.
For example, the LoginID has a value of user1. If you specify Username=%s in the Search Specification field, the resulting string is Username=user1. This string is verified against the user store to find the correct record for authentication.
Copyright © 2014 CA.
All rights reserved.
|
|