Previous Topic: Validate Signed AuthnRequests and SLO Requests/ResponsesNext Topic: How to Configure a SAML 2.0 Authentication Scheme


Configure CA SiteMinder® as a SAML 2.0 Service Provider

This section contains the following topics:

CA SiteMinder® as a Service Provider

Prerequisites for a CA SiteMinder® Relying Partner

How to Configure a SAML 2.0 Authentication Scheme

Select the Authentication Scheme Type

Specify the General Information for the SAML 2.0 Auth Scheme

Locate User Records for SAML 2.0 Authentication

Configure Single Sign-on at the SP

Enable Single Logout

Digital Signing Options at the Service Provider

Enforce Assertion Encryption Requirements for Single Sign-on

Create a Custom SAML 2.0 Authentication Scheme (optional)

IDP Discovery Configuration at the Service Provider

Customize Assertion Processing with the Message Consumer Plug-in

Supply SAML Attributes as HTTP Headers

Specify Redirect URLs for Failed SAML 2.0 Authentication

Request Processing with a Proxy Server at the SP

Enable Client Certificate Authentication for the Back Channel (optional)

How To Protect Resources with a SAML 2.0 Authentication Scheme

CA SiteMinder® as a Service Provider

CA SiteMinder® or CA SiteMinder® SPS federation gateway can act as a SAML 2.0 Service Provider. The Service Provider uses the assertions that it receives from an Identity Provider to authenticate users and then provide access to the requested federation resources. Assuming that the CA SiteMinder® Service Provider has access to a user store at its site, the Service Provider uses the CA SiteMinder® SAML 2.0 authentication scheme to authenticate users.

The SAML 2.0 authentication scheme enables cross-domain single sign-on. The Service Provider is able to consume an assertion from an Identity Provider, identify a user, and establish a CA SiteMinder® session. After a session is established, the Service Provider can authorize the user for specific resources.

The following illustration shows the components for authentication at the Service Provider.

Note: A site can be both an Identity Provider and a Service Provider.

The major components for SAML 2.0 authentication are shown in the following illustration.

Graphic showing the major components required for SAML 2.0 authentication

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 SAML 2.0 authentication scheme is configured at the Policy Server that resides at the Service Provider site. The authentication scheme invokes the Assertion Consumer Service, a component of the Federation Web Services application, that is installed on the Web Agent or SPS federation gateway at the Service Provider site. The service obtains information from the SAML authentication scheme, then uses that information to extract the necessary information from a SAML assertion.

The SAML assertion becomes the user credentials to log in to the Service Provider Policy Server. The user is authenticated and authorized, and if authorization is successful, the user is redirected to the target resource.

Note: The Assertion Consumer Service accepts AuthnRequests that include an AssertionConsumerServiceIndex value of 0. All other values for this setting are denied.

SAML Authentication Request Process

The following illustration shows how the SAML 2.0 authentication scheme processes requests.

Graphic showing the SAML 2.0 Authentication Request Process 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.

The functional flow for authentication is as follows:

  1. A user makes a request for a Service Provider resource. This request goes to the AuthnRequest service at the Service Provider. The request is then redirected to the Identity Provider to obtain a SAML assertion.
  2. The Identity Provider returns a response to the Service Provider.

    For HTTP-POST binding, the response contains the assertion. For the HTTP-Artifact binding, the response contains a SAML artifact.

  3. The Assertion Consumer Service at the Service Provider receives the response message and determines whether the POST or Artifact binding is being used.

    For the HTTP-Artifact binding, the Assertion Consumer Service sends the artifact to the Identity Provider to retrieve the assertion. The Identity Provider returns a response that contains the assertion. The Assertion Consumer Service uses the response with the assertion as credentials to the Policy Server.

  4. The Policy Server invokes the SAML 2.0 authentication scheme by passing the response message with the user credentials to the scheme to be authenticated.
  5. The user disambiguation process begins.
  6. After the disambiguation phase is complete, the SAML 2.0 authentication scheme validates the credentials in the assertion. The scheme also validates the assertion for time validity, and, if applicable, verifies that a trusted Identity Provider signed the assertion.

    Note: For the POST binding, a signature is required. If a signature is not present, authentication fails. For the Artifact binding, a signed assertion is optional because the assertion is obtained over a secure channel between the Service Provider and Identity Provider.

    If single logout is enabled, the SLO servlet redirects the user to a No Access URL.

Prerequisites for a CA SiteMinder® Relying Partner

For CA SiteMinder® to serve as the relying partner, complete following tasks: