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

User Provisioning at the Relying Party

In a federated network, the relying party can establish accounts for users federating from different asserting parties. Dynamic provisioning supports the process of creating client accounts with the necessary account rights and access privileges for accessing data and applications.

Remote Provisioning

Remote provisioning employs a third-party provisioning application to create a user account. The application then passes the necessary information back to the Policy Server at the federation system with CA SiteMinder® Federation. The Policy Server uses the data to create a user credential.

Remote provisioning occurs at the relying party. The following figure shows a remote provisioning setup.

The high-level provisioning process is as follows:

1. The Policy Server at the relying party receives a request for a resource along with an assertion. However, the user cannot be found in the user directory.
2. With provisioning enabled, the Policy Server processes an active response containing assertion data and generates a cookie with the assertion data. Additionally, a cookie that keeps state is generated to indicate a provisioning request is in place.
3. The browser is redirected with an open-format cookie or headers to a provisioning application.
4. The provisioning application typically prompts the user to log in. After the user logs in, the application reads the cookie or the headers. The application uses the assertion data and the login credentials to establish a user account.

   The provisioning application can consume the open-format cookie using the CA SiteMinder® Federation Java or .NET SDK.

5. The browser redirects the user back to the assertion consumer service at the relying party after an account has been provisioned. A cookie that maintains state information about provisioning is examined to verify that the user has been provisioned. A credential is created and passed to the authentication scheme.

   Note: The provisioning application must know the URI of the assertion consumer service at the relying party. For example, the SAML 2.0 URI for CA SiteMinder® as the relying party is https://sp_server:port/affwebservices/public/saml2assertionconsumer.

6. The Policy Server attempts user disambiguation a second time. Assuming that provisioning is successful, the user is authenticated and cookies or headers are sent to the target application.

   The redirect mode that you select for the target application determines the data delivery method to the target application.

7. The user is redirected to the target resource.

Delivery of Assertion Data to the Provisioning Application

To accomplish remote provisioning, CA SiteMinder® redirects the browser with the assertion data to the provisioning application.

CA SiteMinder® can pass the assertion data using one of these methods:

Open format cookie

Delivers SAML assertion information in an open-format cookie. The cookie contains a login ID based on the assertion data.

Note: If you use the open-format cookie, the CA SiteMinder® system and the remote provisioning system must be in the same domain.

The cookie can be created in one of two ways:

• A CA SiteMinder® Federation SDK creates the cookie.

  If you select one of the FIPS algorithms (AES algorithms), use a CA SiteMinder® Federation SDK to generate the cookie. If you are planning to use the .NET SDK, use only the AES128/CBC/PKCS5Padding encryption algorithm. If the provisioning application uses .NET, the .NET SDK on the provisioning server reads the open format cookie.

  The provisioning application must use the same language as the SDK that it is using to create a 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.

• You manually create an open-format cookie.

  To create an open-format cookie without using a CA SiteMinder® Federation SDK, use any programming language. Review the details about the contents of the open-format cookie.

  The language for writing the cookie must support UTF-8 encoding and any of the PBE encryption algorithms that you can select in the Administrative UI.

  If you select FIPS-compatible (AES) algorithm to encrypt the cookie, the provisioning application must use an SDK to read the open-format cookie.

  Verify that the open-format cookie gets set in the browser.

Open-format Cookie Post

The Open-format Cookie Post is similar to the open-format cookie, but it sends the data in the form of an HTTP-POST request. Use this option if you are concerned that data can be lost due to the cookie data limitations.

HTTP Headers

CA SiteMinder® can also pass assertion information as HTTP headers. If you use HTTP headers, the CA SiteMinder® system and the remote provisioning system can be in different domains.

Learn more about using HTTP headers to pass assertion data and how to protect the headers.

The delivery option is configurable in the Application Integration step of the partnership wizard.

After the user is redirected to the provisioning application, CA SiteMinder® no longer has control over the process. If provisioning a user account is a time-consuming process, the provisioning application is responsible for handling this situation. For example, by the application can send a message to the user explaining that provisioning is in process. This information lets the user know not to keep trying to log in before a user account is available.

Remote Provisioning Configuration

To configure remote provisioning, determine a delivery option for the assertion data and supply the URL of the provisioning server.

In addition to configuring remote provisioning, you can select the Allow IdP to create User Identifier option. This option enables the IdP to create a persistent identifier if no identifier for the user exists. This Allow/Create feature is not exclusively for provisioning using local account linking, though it is required for the local method.

When you want the IdP to generate a user identifier that is sent with other attributes, you can enable the Allow/Create feature together with remote provisioning. The application at the remote provisioning server determines how it uses the generated identifier. The application can perform local account linking, but not CA SiteMinder® local account linking.

To configure remote provisioning

1. Begin at the Application Integration step of the partnership wizard.
2. Select the provisioning type in the User Provisioning section.
3. If you select Remote as the provisioning type, complete the additional fields that are displayed.

   Click Help for a description of the fields.

4. Select the Confirm step and click Finish to save your changes.

You have completed remote provisioning configuration.

Failed Authentication Handling Using Redirect URLs (Relying Party)

Assertion-based authentication can fail at the site that consumes assertions. If authentication does fail, you can configure the Policy Server to redirect the user to different applications (URLs) for further processing. For example, when user disambiguation fails, you can configure CA SiteMinder® to send the user to a provisioning system. Setting up redirect URLs is optional and is only configurable at the relying party.

Follow these steps:

1. Begin at the Application Integration step of the partnership wizard.

   In the Status Redirect URL section of the dialog, specify redirects only for the specific failure conditions that you want. For SAML 2.0, you can also configure redirects for specific HTTP error conditions.

   Click Help for a description of the fields.

2. For each redirect option you configure, specify the method by which CA SiteMinder® redirects the user. The options are:

   302 No Data (default)

   Redirects the user with an HTTP 302 redirect and no data.

   HTTP Post

   Redirects the user with the HTTP Post protocol.

Configuration of the redirect URLs is complete.