Federation Guides › Legacy Federation Guide › Configure CA SiteMinder® as a SAML 2.0 Service Provider › Configure Single Sign-on at the SP

Configure Single Sign-on at the SP

To establish single sign-on between the Identity Provider and the Service Provider, specify the SSO bindings.

The SSO settings let you configure single sign-on using the artifact or POST binding.

Part of the single sign-on configuration is defining the Redirect Mode setting. The Redirect Mode specifies how CA SiteMinder® sends assertion attributes, if available, to the target application. You can send assertion attributes as HTTP Headers or HTTP cookies.

The HTTP headers and HTTP cookies have size restrictions that assertion attributes cannot exceed. The size restrictions are as follows:

• For HTTP headers, CA SiteMinder® can send an attribute in a header up to the web server size limit for a header. Only one assertion attribute per header is allowed. See the documentation for your web server to determine the header size limit.
• For HTTP cookies, CA SiteMinder® can send a cookie up to the size limit for a cookie. Each assertion attribute is sent as its own cookie. The cookie size limit is browser-specific, and that limit is for all attributes being passed to the application, not for each attribute. See the documentation for your web browser to determine the cookie size limit.

To configure single sign-on

1. Navigate to the SAML 2.0 authentication scheme.
2. Click SAML 2.0 Configuration, SSO.
3. Complete entries for the SSO fields.

   Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.

4. (Optional) Specify a target resource for single sign-on to work. The target specifies the requested resource at the destination Service Provider site.

   The Service Provider does not have to use the default target. The link that initiates single sign-on can contain a query parameter that specifies the target.

5. In the Bindings section, you can select HTTP-Artifact and HTTP-Post.

   If HTTP-POST is selected and artifact is not selected, only the POST binding is accepted from the Identity Provider. If no binding is specified, the default is HTTP-artifact.

   If you select HTTP-Artifact binding:

   • Enable the session server to store the assertion before it is retrieved.
   • Configure the back channel. Select the type of authentication scheme protecting communication with the Artifact Resolution Service. This service retrieves the assertion at the Identity Provider.
   • Optionally, specify an integer as an Index entry for each binding.

     If you have multiple endpoints, you can configure indexed endpoints. The Service Provider includes the specified endpoint entry as a query parameter in the AuthnRequest. The AuthnRequest is sent to the single sign-on service at the Identity Provider.

More Information:

Configure the Authentication Scheme that Protects the Artifact Service

Enforcing a Single Use Policy to Enhance Security

A single use policy prevents SAML 2.0 assertions from being reused at a Service Provider to establish a second session. This feature applies to assertions that arrive by way of the POST binding.

Note: Single use policy feature is enabled by default when you select the HTTP-POST binding.

Designating an assertion for one time use is an additional security measure for authenticating across a single sign-on environment. From a browser, an attacker can acquire a SAML assertion that has been used to establish a CA SiteMinder® session. The attacker can then POST the assertion to the Assertion Consumer Service at the Service Provider to establish a second session. However, if the assertion is designated for one-time use, this type of risk is mitigated.

CA SiteMinder® enforces a single use policy using expiry data. Expiry data is time-based data about the assertion. The SAML 2.0 authentication scheme stores the expiry data in the session store. Expiry data verifies that a SAML 2.0 POST assertion is only used a single time.

How the Single Use Policy is Enforced

Upon successful validation of a SAML 2.0 assertion, the authentication scheme writes assertion data in the expiry data table. The data includes an assertion ID key and an expiration time. The session store management thread in the Policy Server deletes expired data from the expiry data table.

If the scheme tries to validate assertion data and an expiry data entry has the same assertion ID key, writing assertion data fails. If the scheme cannot write to the expiry table, the SAML 2.0 authentication scheme denies the authentication in the same manner as an invalid assertion.

If the database is unavailable, single use of the assertion cannot be enforced. Consequently, the authentication scheme denies the request and the assertion is not reused.

Configure a Single Use Policy

To configure a single use policy

1. Navigate to the SAML 2.0 authentication scheme.

   Click Modify, SAML 2.0 Configuration.

2. Select to the SSO tab.
3. In the HTTP-Post, section the Enforce Single Use Policy check box is selected by default.
4. Enable the session store.

   For instructions on enabling the session store, see the Policy Server Administration Guide.

More Information:

Storing User Session, Assertion, and Expiry Data

Enforcing a Single Use Policy to Enhance Security

Permit the Creation of a Name Identifier for SSO

As part of a single sign-on request, a Service Provider can generate an AuthnRequest that includes an attribute named AllowCreate, which is set to true. The Service Provider wants to obtain an identity for the user. Upon receiving the AuthnRequest, the Identity Provider generates an assertion. The Identity Provider searches the appropriate user record for the assertion attribute serving as the Name ID. If the Identity Provider cannot find a value for the NameID attribute, it generates a persistent identifier. The Allow/Create feature enables the creation of the identifier.

The persistent identifier is a randomly generated ID. The Identity Provider uses this identifier as the value of the Name ID attribute and places it in the assertion. The Identity Provider then returns the assertion to the Service Provider. For example, if the NameID attribute is set to telephone and there is no value for telephone in the user record, the NameID is set to the randomly generated identifier.

When the Service Provider receives the assertion, the SAML 2.0 authentication scheme processes the response. The scheme then performs a user lookup in its local user store. If the Service Provider locates the user record, it grants the user access.

Enable the Allow/Create feature at the Identity Provider for the Identity Provider to generate a unique identifier. The Identity Provider only generates the identifier if the feature is enabled. The normal flow of assertion generation continues after an entry is made in the Identity Provider log file that a unique identifier was not created.

Include an Allow/Create Attribute in Authentication Requests

To permit the Identity Provider to create an identifier for the Name ID, include the Allow/Create attribute in the AuthnRequest message.

Note: The administrator at the Identity Provider must enable the Allow/Create feature for the identifier to be generated.

Follow these steps:

1. Navigate to the SAML 2.0 authentication scheme.
2. Click SAML 2.0 Configuration, SSO.
3. Check the Allow IDP to Create New Identifier check box.
4. Click OK.

Configure the Back Channel for HTTP-Artifact SSO

If you select the HTTP-Artifact binding for single sign-on, select an authentication scheme to secure the back channel to the Artifact Resolution Service. This service retrieves the assertion at the Identity Provider.

To configure the back channel

1. Navigate to the SAML 2.0 authentication scheme.
2. Click SAML 2.0 Configuration, Encryption and Signing.
3. In the Backchannel section, complete all the fields.

   Important! If you are using basic authentication for the backchannel authentication scheme, the value of the SP Name field is the name of the Service Provider. No additional configuration is necessary. If you are using client certificate authentication, the SP Name field must be the alias of the client certificate stored in the certificate data store. The SP uses the certificate as a credential to gain access to the Artifact Resolution Service.

4. Click OK to save your configuration.

More Information:

Enable Client Certificate Authentication for the Back Channel (optional)

ECP Configuration at the Service Provider

To configure ECP, enable the feature at the Identity Provider and the Service Provider. The following procedure is for a CA SiteMinder® Service Provider.

For more information about ECP, read the overview.

Follow these steps:

1. Direct requests for a protected resource to the AuthnRequest service at the Service Provider. The following URL shows an example:

   https://host:port/affwebservices/public/saml2authnrequest

2. Log in to the Administrative UI at the Service Provider.
3. Modify the relevant SAML 2.0 authentication scheme object.
4. Click SAML 2.0 Configuration in the Scheme Setup section.

   The configuration tabs for the scheme are displayed.

5. Select the SSO tab.
6. Select the Enhanced Client and Proxy Profile check box then click OK.
7. Click Submit to save the changes.

The CA SiteMinder® Service Provider can now process ECP calls.

Note: A single SAML Service Provider object can handle artifact, POST, SOAP, and PAOS bindings for single sign-on requests. SOAP and PAOS are the bindings for the ECP profile. The Identity Provider and Service Provider determine the binding being used based on the parameters in a request.