Previous Topic: Mapping Assertion Attributes to Application Attributes (SAML Only)Next Topic: Failed Authentication Handling Using Redirect URLs (Relying Party)

CA SiteMinder® Federation Standalone Guide › Application Integration at the Relying Party › Dynamic Provisioning of a User Identity at the Relying Party

Dynamic Provisioning of a User Identity at the Relying Party

In a federated network, it is not uncommon for the relying party to establish accounts for users federating from different asserting parties. Dynamic provisioning lets CA SiteMinder® Federation Standalone support the process of creating client accounts with the necessary account rights and access privileges for accessing data and applications.

CA SiteMinder® Federation Standalone offers two methods to support provisioning:

Each method is described in the following sections.

Local Account Linking for Provisioning

You can use local account linking to implement provisioning only for SAML 2.0 deployments. Provisioning occurs by linking a user account at the IdP to an account at the SP.

The local account linking process is as follows:

  1. A user requests access to a federated target resource at the SP.
  2. The SP generates an AuthnRequest that includes an attribute named AllowCreate, which is set to true. The SP sends the AuthnRequest to the IdP to obtain an identity for the user.
  3. Upon receiving the AuthnRequest, the IdP generates an assertion. During assertion generation, the IdP searches for the appropriate user record for the attribute that is configured to serve as the Name ID in the assertion.
  4. If the IdP cannot find a value for the attribute being used for the NameID, the IdP generates a persistent identifier, assuming the feature to create an identifier is enabled.

    The persistent identifier is a randomly generated ID. The IdP uses this identifier as the value of the Name ID attribute and places it in the assertion. The IdP then returns the assertion to the SP.

    Note: The Allow/Create feature must be configured at both sites. If the IdP is not configured to create an identifier, regardless of whether the Allow/Create attribute is in the AuthnRequest message, assertion generation fails.

  5. CA SiteMinder® Federation Standalone at the SP processes the assertion from the IdP, but it cannot find the user record because the NameID value does not exist at the SP. As a result, authentication fails.
  6. The failed authentication attempt triggers a redirect to a linkaccount.jsp page with all the assertion and other data that the Assertion Consumer Service passes to it.
  7. The user is required to authenticate with local credentials before gaining access to the linkaccount.jsp page. The successful login identifies the user. CA SiteMinder® Federation Standalone references the appropriate user record in the local user directory and creates a session for that user. The user still does not get access to the originally requested federated resource.
  8. The linkaccount.jsp passes the assertion and all other data back to the Assertion Consumer Service. CA SiteMinder® Federation Standalone authenticates the user with the assertion again. Now that there is a session that identifies the user, CA SiteMinder® Federation Standalone populates the proper user record in the local user directory with the persistent identifier from the assertion. CA SiteMinder® Federation Standalone stores the persistent identifier in an attribute that you configure specifically for this purpose. The account at the IdP is now linked with the account at the SP. Authentication succeeds.
  9. Finally, CA SiteMinder® Federation Standalone redirects the user the requested resource.

Note: Local account linking requires the use of the Allow IdP to create User Identifier feature; however, the AllowCreate feature is not exclusively for local account linking. You can select this feature without wanting to implement local account linking.

Configure Local Account Linking (SAML 2.0)

Implementing the local account linking method of provisioning requires configuration at the Identity Provider and Service Provider.

To configure local account linking at the Identity Provider

  1. Access the partnership wizard and navigate to the Assertion Configuration step in the partnership wizard.
  2. Configure the required fields in the Name ID group box.

    In these fields is where you determine the attribute used for the NameID in the assertion.

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

  3. Select the Allow Creation of User Identifier check box.
  4. Select the Confirm step the Partnership wizard and click Finish to save your changes.

Configuration at the Identity Provider is complete.

To configure local account linking at the Service Provider

  1. Access the Partnership wizard and navigate to the User Identification step.
  2. In the Choose Identity Attribute from Assertion group box:
  3. Enter a value for the Search Specification field.

    The Search Specification value is the attribute CA SiteMinder® Federation Standalone uses to look up the user and to store the persistent identifier sent from the IdP. For example, if buyerID should store the value of the NameID, set the string to buyerID=%s.

  4. Navigate to the Application Integration step.
  5. Select Local Account Linking for the Provisioning Type field in the User Provisioning section of the dialog.

    Selecting this option automatically configures the User Not Found URL to the linkaccount.jsp page with a method of POST. This URL is where CA SiteMinder® Federation Standalone redirects the user after the first failed authentication attempt.

  6. (Optional) Customize the linkaccount.jsp file to provide a custom user experience when the user is redirected after a failed authentication attempt. This file must POST the accountlinking and samlresponse parameters back to the Assertion Consumer Service. The accountlinking parameter must be set to yes. The page is in federation_install_dir/secure-proxy/Tomcat/webapps/affwebservices/public.
  7. Select the Confirm step in the Partnership wizard and click Finish to save your changes.

Remote Provisioning

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

The following figure shows how a remote provisioning setup can be configured.

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 Standalone 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, the federation system redirects the browser with the assertion data to the provisioning application.

The federation system can pass the assertion data using one of the following methods:

Legacy cookie

Delivers SAML assertion information in a legacy cookie generated by the federation system. The cookie contains a login ID based on the assertion data. If a legacy cookie is used, then the CA SiteMinder® Federation Standalone Java SDK must be installed on the system with the provisioning application so that the provisioning application can read the legacy cookie.

Note: If you use the legacy cookie, the federation system and the remote provisioning system must be in the same domain.

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 federation system and the remote provisioning system must be in the same domain.

The cookie can be created in one of two ways:

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

If proxy mode is used, this information can also be passed as HTTP headers. If you use HTTP headers, the CA SiteMinder® Federation Standalone system and the remote provisioning system can be in different domains.

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® Federation Standalone 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 sending a message to the user that provisioning is in process. This information lets the user know not to keep trying to log in before an user account is available.

Remote Provisioning Configuration

Configuring remote provisioning requires that you determine a delivery option of 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.

You can enable the Allow/Create feature together with remote provisioning, if you want the IdP to generate a user identifier that is sent with other attributes to the remote provisioning server. The application at the remote provisioning server determines how it uses the generated identifier. The application can perform local account linking; however, this is not CA SiteMinder® Federation Standalone 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 group box.

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

  3. If you select Remote as the provisioning type, complete the following additional fields:
  4. If you specify open format cookie as the delivery option, you must complete the additional settings in the Open-format Cookie group box.

    These settings include the name of the cookie, the algorithm that encrypts the cookie and the encryption password. Optionally, you can enable an HMAC function to verify the integrity of the cookie.

  5. Select the Confirm step in the wizard and click Finish to save your changes.

You have completed remote provisioning configuration.

More information:

Delivery of Assertion Data to the Provisioning Application