Features of Federation

Access Manager provides a web interface to the Liberty Identity Federation Framework (Liberty ID-FF) which is accessible through the Federation tab in the Access Manager Console. The Federation component includes the features and functions described in the following sections.

For more information about the Liberty ID-FF functions, see the Liberty ID-FF Protocols and Schema Specifications.

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.

Authentication and Authentication Context

Single sign-on is the means by which a provider of either type can convey to another provider that the principal has been authenticated. Identity providers use local (to the identity provider) session information that is mapped to a user agent as the basis for issuing SAML authentication assertions to service providers. Thus, when the principal uses a user agent to interact with a service provider, the service provider requests authentication information from the identity provider based on the user agent's session information. If this information indicates that the user agent's session is presently active, the identity provider will return a positive authentication response to the service provider.

Access Manager accommodates these authentication actions:

• Supports a range of authentication methods (for example, password or certificate-based SSL).

• Allows providers to exchange the following minimum set of authentication information with regard to a principal: authentication status (active or not), instant (time authenticated), method, and pseudonym (temporary or persistent).

• Allows an identity provider, at the discretion of the service provider, to authenticate a principal by using an identity provider other than itself (proxy) and relay this information back to the service provider.

SAML is used for provider interaction during authentication but not all SAML assertions are equal. Different authorities issue SAML assertions of different quality. Therefore, the Liberty Alliance Project defines how the consumer of a SAML assertion can determine the amount of assurance to place in the assertion. This is referred to as the authentication context, information added to the SAML assertion that gives the assertion consumer information they need to make an informed entitlement decision. For example, a principal uses a simple identifier and a self-chosen password to authenticate to an identity provider. The identity provider sends an assertion that states the principal has been authenticated to a service provider. By sending the authentication context, the service provider can place the appropriate level of assurance on the associated authentication assertion. For example, if the service provider were a bank, they might require stronger authentication than that which has been used and send a response to the identity provider with a request to authenticate the user again. The authentication context information might include:

• The initial user identification mechanism (for example, face-to-face, online, or shared secret).

• The mechanisms for minimizing compromise of credentials (for example, private key in hardware, credential renewal frequency, or client-side key generation).

• The mechanisms for storing and protecting credentials (for example, Smartcard, or password rules).

• The authentication mechanisms (for example, password or Smartcard with PIN).

An XML schema has been defined by which the authority can assert the context of the SAML assertions it issues. The Liberty Alliance Project specifications have also defined Authentication Context classes against which an identity provider can claim conformance. The Liberty-defined authentication contexts are listed and described in the following table.

For more information on authentication context, see the Liberty ID-FF Authentication Context Specification.

Identifiers and Name Registration

Access Manager supports name identifiers that are unique across all providers in an authentication domain. This identifier can be used to obtain information for or about the principal (with consent) without requiring the user to consent to a long-term relationship with the service provider. During federation, the identity provider generates an opaque value that serves as the initial name identifier that both the service provider and the identity provider use to refer to the principal when communicating with each other.

After federation though, the identity provider or the service provider may register a different opaque value. The reasons for doing this would be implementation-specific. If a service provider registers a different opaque value for the principal, the identity provider must use the new identifier when communicating with the service provider about the principal.

The initial name identifier defined by the identity provider is always used to refer to the principal unless a new name identifier is registered.

Global Logout

A principal may establish authenticated sessions with both an identity provider and individual service providers, based on authentication assertions supplied by the identity provider. When the principal logs out of a service provider session, the service provider sends a logout message to the identity provider that provided the authentication for that session. When this happen, or the principal manually logs out of a session at an identity provider, the identity provider sends a logout message to each service provider to which it provided authentication assertions under the relevant session. The one exception is the service provider that sent the logout request to the identity provider.

Dynamic Identity Provider Proxying

An identity provider can choose to proxy an authentication request to an identity provider in another authentication domain if it knows that the principal has been authenticated with this identity provider. The proxy behavior is defined by the local policy of the proxying identity provider. However, a service provider can override this behavior and choose not to proxy. This function can be implemented as a form of authentication when, for instance, a roaming mobile user accesses a service provider that is not part of the mobile home network. For more information see Dynamic Identity Provider Proxying.