Federation Guides › Partnership Federation Guide › Application Integration at the Relying Party

Application Integration at the Relying Party

This section contains the following topics:

Relying Party Interaction with Applications

Redirecting a User to the Target Application

Using HTTP Headers to Pass Assertion Data (SAML only)

Mapping Assertion Attributes to Application Attributes (SAML only)

User Provisioning 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

Redirecting a User to the Target Application

The Target Application section in the Application Integration step lets you define how a user gets redirected to the target application. The redirection method that you select depends on the type of data you want to pass 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. Note the following information:
   • If you select Cookie Data, you can URL-encode attribute data in the cookie by selecting the URL Encode Attribute Cookie Data check box. This option is only for SAML 1.1 and 2.0.
   • If you select the Open-format Cookie or the Open-format Cookie Post options, 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 Policy Server passes all values to the target application in the cookie.

   • If you select one of the FIPS-compatible algorithms (AES algorithms), use a CA SiteMinder® Federation SDK to generate the open-format cookie. If you use the .NET SDK, use only the AES128/CBC/PKCS5Padding encryption algorithm.

     The target application must use the same language as the SDK that creates the cookie. If you are using the CA SiteMinder® Federation Java SDK, the application must be in Java. If you are using the .NET SDK, the application must support .NET.

   • If you select HTTP Headers as the redirect mode, CA SiteMinder® can deliver multiple attribute values in a single header. Separate each attribute value with a comma. This option is only for SAML 1.1 and 2.0.

     Learn more about using HTTP Headers as the redirect mode and how to protect the headers.

   Click Help for a description of the fields.

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

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

   For SAML 2.0, you can leave this field blank if you override it with the RelayState query parameter. The RelayState query parameter can part of the URL that triggers 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 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. Navigate to web_agent_home/conf and modify the WebAgent.conf file. Uncomment the following entry so it appears as follows:

   Windows

   LoadPlugin="path\SAMLDataPlugin.dll"

   UNIX

   LoadPlugin="path/SAMLDataPlugin.so"

3. (Optional but recommended) Add the setting fedheaderprefix setting to the appropriate Agent Configuration Object for the web agent. Enter any string as a prefix.

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

4. 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.