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:

Install a policy agent in a web container to protect the application and pass the HTTP_HEADER and REMOTE_USER variables to the application to capture the user credentials. You may or may not need a custom authentication module.
Customize the application's authentication module to create an SSOToken from the request object or from the SSO cookie. Afterwards, retrieve the user credentials using the SSO API and create a session using the application's API.

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:

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.

Additionally, Access Manager can accommodate the following:

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. 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:

Use a policy agent to insert HTTP header variables into the request object. This functions for Web applications only.
Use the authentication API to validate and retrieve user identities. This will work with either Web or non-Web applications.

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:

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)
- Authentication method
- 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 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 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, smart card, or password rules).
The authentication mechanisms (for example, password or smart card with PIN).

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


Class	Description
MobileContract	Identified when a mobile principal has an identity for which the identity provider has vouched.
MobileDigitalID	Identified by detailed and verified registration procedures, a user's consent to sign and authorize transactions, and DigitalID-based authentication.
MobileUnregistered	Identified when the real identity of a mobile principal has not been strongly verified.
Password	Identified when a principal authenticates to an identity provider by using a password over an unprotected HTTP session.
Password-ProtectedTransport	Identified when a principal authenticates to an identity provider by using a password over an SSL-protected session.
Previous-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.
Smartcard	Identified when a principal uses a smart card to authenticate to an identity provider.
Smartcard-PKI	Identified when a principal uses a smart card with an enclosed private key and a PIN to authenticate to an identity provider.
Software-PKI	Identified when a principal uses an X.509 certificate stored in software to authenticate to the identity provider over an SSL-protected session.
Time-Sync-Token	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.