Previous Topic: Mapping Assertion Attributes to Application Attributes (SAML only)Next Topic: Failed Authentication Handling Using Redirect URLs (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.

Provisioning set up at the relying party

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:

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.

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

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

You have completed remote provisioning configuration.