Identity Federation and Single Sign-On

Let's assume that a principal has separate user accounts with both a service provider and an identity provider in the same authentication domain. In order to gain access to these individual accounts, the principal authenticates with each provider. After the principal has authenticated with the service provider though, they can be given the option to federate the service provider account with an identity provider account. Consenting to the federation of these two accounts links them for the purpose of single sign-on.

Providers differentiate between federated users by defining a unique handle for each account. (They are not required to use the principal's actual provider account identifier.) Providers can also choose to create multiple handles for a particular principal. However, identity providers must create one handle per user for each service provider that has multiple web sites so that the handle can be resolved across all of them.

Because both the identity provider and service provider in a federation need to remember the principal's handle, they create entries that note the handle in their respective user repositories. In some scenarios, only the identity provider's handle is conveyed to a service provider. For example, if a service provider does not maintain its own user repository, the identity provider's handle is used.

Access Manager can accommodate the following functions:

• Providers of either type give the principal notice upon identity federation or identity defederation.

• Providers of either type notify each other regarding a principal's defederation.

• Identity providers notify the appropriate service providers regarding a principal's account termination.

• Providers of either type give the principal a list of their federated identities.

• Users can terminate federations or defederate identities.

Auto-Federation

Auto federation will automatically federate a user's disparate provider accounts based on a common attribute. During single sign-on, if it is deemed a user at provider A and a user at provider B have the same value for the defined common attribute (for example, an email address), the two accounts will be federated without consent or interaction from the principal. For more information, see Auto-Federation.

Bulk Federation

Federating one user's service provider account with their identity provider account generally requires the principal to visit both providers and link them. In situations when an enterprise is both a service provider and an identity provider, the organization should have the ability to federate user accounts behind the scenes. Access Manager provides a script for federating user accounts in bulk. The script allows the administrator to federate many (or all) of a principal's provider accounts based on metadata passed to the script. Bulk federation is useful when adding a new service provider to an enterprise so you can federate a group of existing employees to the new service. For more information, see Bulk Federation.