CA SiteMinder® Federation Standalone Guide › Application Integration at the Relying Party

Application Integration at the Relying Party

This section contains the following topics:

Relying Party Interaction with Applications

Redirect a User to the Target Application

Using HTTP Headers to Pass Assertion Data (SAML only)

Mapping Assertion Attributes to Application Attributes (SAML Only)

Dynamic Provisioning of a User Identity at the Relying Party

Failed Authentication Handling Using Redirect URLs (Relying Party)

Relying Party Interaction with Applications

The Application Integration step of the partnership wizard is applicable only at the relying party. This step lets you define various aspects of federated operation for resolving user identities and directing users to the target application.

The features that you can configure in the Application Integration step are:

• User redirection to the target application
• Mapping assertion attributes to application attributes (SAML only)
• Provisioning a user identity
• User redirection in case of an authentication failure

Redirect a User to the Target Application

The Target Application group box in the Application Integration step lets you define how a user gets redirected from CA SiteMinder® Federation Standalone to the target application. There are several methods from which to choose. The redirection method you select depends on the type of data you want to pass along with the user to the target application.

Follow these steps:

1. Navigate to the Application Integration step in the Partnership wizard.
2. Select a redirection method for the Redirect Mode field.
   • If you select Cookie Data, you can URL-encode attribute data in the cookie by selecting the URL Encode Attribute Cookie Data check box.
   • If you select the Open-format Cookie or the Open-format Cookie Post option, configure the additional required settings and optional settings. Unlike the Open-format Cookie, the Open-format Cookie Post sends the data in the form of an HTTP-POST request.

     If the relying party receives an assertion with multiple attribute values, the federation system passes all values to the target application in the cookie.

   • If you select one of the FIPS-compatible algorithms (AES algorithms), you are required to use a CA SiteMinder® Federation Standalone SDK to consume the open format cookie. If you use the .NET SDK, you are required to use the AES128/CBC/PKCS5Padding encryption algorithm.
   • If you configured CA SiteMinder® Federation Standalone in proxy mode and you select HTTP Headers as the redirect mode, CA SiteMinder® Federation Standalone can deliver multiple attribute values in a single header by separating each value with a comma.

   Note: Click Help for a description of fields, controls, and their respective requirements.

3. Enter the URL of the target application in the Target field.

   If CA SiteMinder® Federation Standalone is operating in proxy mode, enter the URL for the proxy host because the proxy handles all federation requests locally. The proxy host can be any system that sits in front of CA SiteMinder® Federation Standalone. The proxy host can also be CA SiteMinder® Federation Standalone itself, provided CA SiteMinder® Federation Standalone is being accessed directly from the Internet. Ultimately, when operating in proxy mode, the URL you specify as the target must go through CA SiteMinder® Federation Standalone. For example, if the base URL for CA SiteMinder® Federation Standalone is fed.demo.com:5555 and the backend server resource is mytarget/target.jsp, the value for the Target field is http://fed.demo.com:5555/mytarget/target.jsp.

   Note: You specify the backend server that sits behind the proxy host when you run the CA SiteMinder® Federation Standalone Configuration wizard. You can modify the backend server entry by rerunning the Configuration wizard.

   For SAML 2.0, you can leave this field blank if you override it with the value of the Relay State query parameter, which can be included in a URL to trigger single sign-on. To enable this override, select the Relay state overrides target check box.

Setting up redirection to the target is complete.

Using HTTP Headers to Pass Assertion Data (SAML only)

For a SAML entity, the Policy Server can use HTTP headers to pass identity attributes from an assertion to a back-end application. A backend application can be a target application for single sign-on or a user provisioning application. The system passes these headers in an encrypted cookie.

The headers have the same name as the assertion attributes. For example, if the assertion attribute is "address", the application looks for the HTTP header "ADDRESS".

Assertion attributes are case-sensitive, but HTTP headers are not. The Policy Server cannot pass the same attributes that differ only by case sensitivity and then map them to HTTP headers. For example, the system cannot pass "address" and "Address" as headers at the same time. In general, do not use the attributes with the same names that are only different because of case sensitivity or format.

The following additional values are passed as headers:

• NAMEID
• FORMAT
• AUTHNCONTEXT

Protecting HTTP Headers

If an unauthorized user knows the name of an assertion attribute, that user can set this name as a header in a browser. With the header set, the malicious user can gain access to the target application. The target application sees an expected header value and grants access to the resource without CA SiteMinder® consuming an assertion.

Setting a value for the FedHeaderPrefix protects against the following scenario:

1. An unauthorized user learns the names of HTTP headers. These header names include prefixes.
2. The malicious user sends an incoming request, including the headers, to the Policy Server.
3. The Policy Server recognizes that the headers containing prefixes come from an incoming request and are not generated internally so it removes these headers.
4. Before the system passes its own legitimate headers to the back-end application, it adds the specified prefix to each header. The headers are then passed to the application.

Configure HTTP Headers to Pass Assertion Data (SAML only)

CA SiteMinder® can pass assertion data using the HTTP headers.

Follow these steps:

1. Verify that the CA SiteMinder® web agent is installed on the relying party system that is handling federation traffic.
2. (Optional but recommended) Enter any string as a prefix for the HTTP header.

   CA SiteMinder® adds the prefix to all the HTTP headers. Setting a prefix protects HTTP headers against manipulation by an unauthorized user before CA SiteMinder® consumes an assertion. As a result, only legitimate headers get passed to the target application. Read more about protecting HTTP headers.

   To add a prefix to the HTTP header, do the following:

   1. Log in to the Administrative UI.
   2. Click Infrastructure, Deployment Settings.
   3. Specify a string for the HTTP Header Prefix.

      Note: This option is available only for the proxy deployment mode.

   4. Click Save.
3. Do one of the following tasks in the Application Integration step of the partnership wizard:
   • Select HTTP Headers as the Redirect Mode for the target application.
   • Select HTTP Headers as the Delivery Option for user provisioning.

HTTP headers are now configured to pass attribute data.