Federation Manager Guide › Federation Partnerships › Application Integration › Dynamic Provisioning of a User Identity at the Relying Party › Local Account Linking for Provisioning

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. For example, if the attribute for the NameID is set to telephone and there is no value for telephone in the user record, the NameID is set to the randomly generated identifier.

   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. Federation Manager 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. Federation Manager 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. Federation Manager authenticates the user with the assertion again. Now that there is a session that identifies the user, Federation Manager populates the proper user record in the local user directory with the persistent identifier from the assertion. Federation Manager 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, Federation Manager 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.