Sun Java System Access Manager 7.1 Federation and SAML Administration Guide

The Federation Module

The Federation component of Access Manager provides an interface for creating, modifying, and deleting authentication domains and service and identity providers (both remote and hosted types) for implementing a federated model. The web interface for the Liberty ID-FF in Access Manager is accessible from the Federation tab in the Access Manager Console, as shown.

Screen shot of the Federation interface in Access Manager Console

The Federation module includes the capabilities described in the following sections.

More information can be found in Chapter 3, Federation. 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 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 separately. After authenticating with the service provider though, the principal can be given the option to federate the service provider account with the identity provider account. Consenting to the federation of these two accounts links them for the purpose of single sign-on. Single sign-on (SSO) is the means of passing a user's credentials between applications without the user having to reauthenticate each time an application is accessed. With Access Manager, you can achieve SSO in the following ways:

To set up federated SSO, you must first establish SSO. Following this, configure the service provider application and the identity provider in Access Manager to enable federation using the Liberty Alliance Project protocols. Liberty ID-FF 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 service providers that have multiple web sites so that the handle can be resolved across all of them.

Note –

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:

Additionally, Access Manager can accommodate the following:


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. The organization though needs 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 a principal has been authenticated. Authentication is the process of validating user credentials; for example, a user identifier accompanied by an associated password. You can authenticate users with Access Manager in the following ways:

Identity providers use local (to the identity provider) session information mapped to a user agent as the basis for issuing Security Assertion Markup Language (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 provides the following authentication actions:

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 details 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 including the authentication context, the service provider can place the appropriate level of assurance on the associated assertion. If the service provider were a bank, they might require stronger authentication than that which has been used and respond to the identity provider with a request to authenticate the user again using a more stringent context. The authentication context information sent in the assertion might include:

The Liberty Alliance Project specifications define authentication context classes against which an identity provider can claim conformance. The Liberty-defined authentication contexts are listed and described in the following table.

Table 2–1 Authentication Context Classes




Identified when a mobile principal has an identity for which the identity provider has vouched. 


Identified by detailed and verified registration procedures, a user's consent to sign and authorize transactions, and DigitalID-based authentication. 


Identified when the real identity of a mobile principal has not been strongly verified. 


Identified when a principal authenticates to an identity provider by using a password over an unprotected HTTP session. 


Identified when a principal authenticates to an identity provider by using a password over an SSL-protected session. 


Identified when an identity provider must authenticate a principal for a current authentication event and the principal has previously authenticated to the identity provider. This affirms to the service provider a time lapse from the principal's current resource access request. 

Note –

The context for the previously authenticated session is not included in this class because the user has not authenticated during this session. Thus, the mechanism that the user employed to authenticate in a previous session should not be used as part of a decision on whether to now allow access to a resource.


Identified when a principal uses a smart card to authenticate to an identity provider. 


Identified when a principal uses a smart card with an enclosed private key and a PIN to authenticate to an identity provider. 


Identified when a principal uses an X.509 certificate stored in software to authenticate to the identity provider over an SSL-protected session. 


Identified when a principal authenticates through a time synchronization token. 

The procedures in Entities contain a number of attributes related to authentication context. For more information, see the Liberty ID-FF Authentication Context Specification. Additionally, there is an XML schema defined which the identity provider authority can use to incorporate the context of the authentication in the SAML assertions it issues.

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.

Note –

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.