Chapter 5 Federation Management

This chapter explains the concept of identity federation, and describes the role of the Federation Management module in Sun™ Java System Identity Server 2004Q2.

The Need for Federated Identities

Consider the many times an individual accesses services on the Internet in a single day. At work, he uses the company intranet to perform a multitude of business-related tasks such as reading and sending email, looking up information in the company phone book and other internal databases, and submitting expense reports and other business-related online forms. At home after work, he checks his personal email, then logs into an online news service to check his baseball team’s standings. He may finalize his travel plans via his travel agent’s website, and then does some online shopping at his favorite clothing store. Each time he accesses a service on the Internet, he must log in and identify himself to the service provider.

A local identity refers to the set of attributes or information that identify a user to a particular service provider. These attributes typically include a name and password, plus an email address, account number or other identifier. For example, the individual in our scenario is known to his company’s network as an employee number, but he is known to his travel agent as Joe Smith. He is known to his online news service by an account number, and he is known to his favorite clothing store by a different account number. He uses one email name and address for his personal email, and a different email name and address for his workplace. Each of these different user names represents a different local identity.

Identity federation allows a user to consolidate the many local identities he has configured among multiple service providers. With one federated identity, the individual can log in at one service provider’s site and move to an affiliated service provider site without having to re-authenticate or re-establish his identity. For example, with a federated identity, the individual might want to access both his personal email account and his business email account from his workplace, and move back and forth between the two services without having to log in each time. Or at home he might want to log in to an online clothing store, then access the online news service, and communicate with his travel agent. It is a convenience for the user to be able to access all of these services without having to provide different user names and passwords at each service site. It is a valuable benefit to the user when he can do so safely, and knowing that his identity information is secure.

The Liberty Alliance Project

In 2001 Sun Microsystems joined with other major companies to form the Liberty Alliance Project, the premier open standards organization for federated identity and identity-based services. The Liberty Alliance Project develops specifications and guidelines for implementing complete network identity infrastructures and for deploying identity-based web services.

The members of the Liberty Alliance Project represent some of the world's most recognized brand names and service providers, driving products, services and partnerships across a spectrum of consumer and industrial products, financial services, travel, retailing, telecommunications and technology. For more information including listings of Liberty web service products, specifications, cased studies, and white papers, see the Liberty Alliance Project website:

The Circle of Trust

The goal of the Liberty Alliance Project is to enable individuals and organizations to easily conduct network transactions while protecting the individual’s identity. This goal can be achieved only when commercial and non-commercial organizations join together into a circle of trust. In a circle of trust, service providers agree to join together in order to exchange user authentication information using Liberty web service technologies. This circle of trust must contain at least one identity provider, a service that maintains and manages identity information. The circle of trust also includes service providers that offer web-based services to users; it also includes users themselves. Once a Circle Of Trust is established, single sign-on is enabled between all the providers.

The circle of trust is also known as an authentication domain, although it is not a DNS domain or a domain in the Internet sense of the word. Figure 5-1 illustrates a user accessing a small business, a service provider that is associated with other businesses and agencies in a circle of trust.

Account federation occurs when a user chooses to unite distinct service accounts and identity provider accounts. The user retains individual account information with each provider in the circle. At the same time, the user establishes a link that allows the exchange of authentication information between them. Users can choose to federate any or all identities they might have with the service providers that have joined this circle. When a user successfully authenticates with one service provider, she can access any of the her accounts within the circle of trust in a single session without having to reauthenticate.

Federation Management Architecture

The Identity Server 6.1 release implemented an Identity Federation Framework (ID-FF) version 1.1 Identity Server 2004Q2 adds new federation features defined in Identity Federation Framework 1.2 specifications, including a web service framework to facilitate deployment of customer Identity Web Services. Client APIs are provided for web service consumers to communicate with web service providers.

The following three major components make it possible for identity information to be exchanged among service providers:

Identity Federation Framework

Identity Web Services Framework

Identity Service Instance Specifications (ID-SIS)

Identity Federation Framework

Opt-in account linking. Users can choose to federate different service provider accounts.

Authentication context. Service providers with federated accounts communicate the type and level of authentication that should be used when the user logs in.

Identity provider introduction. This feature provides the means for service providers to discover which identity providers a principal uses. A principal can be an organization or individual who interacts with the system. This is important when there are multiple identity providers in an identity federation network.

Name Registration. This feature enables a service provider or identity provider to register with each other a new name identifier for a principal at any time following federation.

Single Sign-on and Federation Protocol TA protocol that defines the process that a user at a service provider goes through to authenticate their identity with an identity provider. It also specifies the means by which a service provider obtains an Authentication Assertion from an identity provider to allow single sign-on to the user. There are two types of Single Sign-On which either the identity or service provider can implement:

SOAP-based Single Sign On and Federation Protocol, which relies on a SOAP call from provider to provider. This is primarily the Browser Artifact SSO profile.

Form POST-based Single Sign On and Federation Protocol, which rely on an HTTP form POST to communicate between providers.

Single Log-Out Protocol. TA protocol used to synchronize the session log-out functionality across all sessions that were authenticated and created by a particular identity provider. There are two types which either the identity or service provider can implement:

SOAP-based Single Log-Out Protocol relies on asynchronous SOAP messaging calls between providers.

HTTP Redirect-based Single Log-Out Protocol

Identity Web Services Framework

The Web Services Framework consists of a set of schema, protocols and profiles for providing a basic identity services, such as identity service discovery and invocation.

Three parties are required for identity federation in a basic Liberty Web Services environment: a user agent, a web service consumer, and a web service provider. Figure 5-2 illustrates the internal architectures of a Liberty Web Services Consumer and a Web Service Provider.

Discovery Service. An identity service that allows a requester to discover resource offerings.

SOAP Binding. A set of Java APIs for sending and receiving ID-* messages using SOAP and XML.

Data Services Template. A common data service layer for developing identity services. Includes common utilities for message error-checking and verification, and remote client APIs to support customer data service instances.

Security Mechanisms. Defines a set of authentication mechanism and security properties which are factored into authorization decisions enforced by the targeting identity-based web services. Each mechanism contains both peer entity authentication (null/TLS/CClientTLS) and message authentication (null/X509/SAML).

Interaction Service. A protocol for simple interaction of Web Services Framework participants with a Principal.

Trusted Authority. APIs for creating security tokens used for authentication and authorization in Liberty II-enabled services.

Identity Service Instance Specifications (ID-SIS)

Personal Profile Service. An instance of a data-oriented web service which offers profile information regrading a principal’s personal life. A shopping portal that offers information such the principal’s account number and shopping preferences is an example of a personal profile service.

Employee Profile Service. Similar to the Personal Profile Service, except that An instance of a data-oriented web service which offers profile information regarding a principal’s workplace. An online corporate phone book that provides an employee name, office building location, and telephone extension number is an example of an employee profile service.

Supporting Components

Metadata Service. A library of command-line tools for loading metadata into the Identity Server data store.

Reverse HTTP Bindings. A protocol and set of APIs for retrieving data from Identity Server via clients such as cell phones.

The Federation Management Process

The Federation Management process begins with authentication. By default, Identity Server comes with two options for user authentication. The first is the proprietary Authentication Service; the second is the Liberty-enabled Federation Management module. With the first option, when a user tries to access a resource protected by Identity Server, he is redirected to the Authentication Service using an Identity Server login page. When the user provides credentials, the Authentication Service verifies his identity, and either allows or denies access.

With Liberty-enabled Federation Management, when a user attempts to access a resource protected by Identity Server, the authentication process begins with a search for a valid Identity Server session token. If a session token is found, the user is granted access to the requested page. The requested page, which belongs to a member of the circle of trust, contains a link which provides the user an opportunity to federate his identity. When the user clicks this link, he is directed through the Federation Single Sign-On Process process. If no session token is found, the user is directed through the Pre-Login Process.

Federation Single Sign-On Process

When a user signs on to access a protected resource or service, Identity Server sends a request to the identity provider for authentication confirmation. If the identity provider sends a positive response, the user gains access to all provider sites within the circle of trust. If the identity provider sends a negative response, the user is directed to authenticate again using the Federation Single Sign-On process.

In federated single sign-on, the user selects an identity provider and then sends his or her credentials for authentication. Once authentication is complete and access is granted, the user is redirected to the Identity Server Authentication Service. The user is automatically granted a session token and redirected to the requested page which contains a link to allow the user to federate his or her identity. As long as the session token remains valid, the user can access other services offered by other service providers in the circle of trust without having to sign on again.

Pre-Login Process

The purpose of the Pre-Login process is to establish a valid user session at the service provider site. When no Identity Server session token is found, the pre-login process begins with the search for another type of cookie, a Federation cookie.

If, after the search for an Identity Server session token proves null, a Federation cookie is found and its value is “no,” an Identity Server login page is displayed and the user submits credentials to the Authentication Service. When authenticated by the Identity Server, the user is redirected to the requested page which contains a link to allow the user to federate their identity. If the user clicks this link, he is directed through the Federation Single Sign-On Process.

If, after the search for an Identity Server session token proves null, a valid Federation Cookie is found an its value is “yes,” it means the user has already been federated but not authenticated by an identity provider within the Circle of Trust. This is confirmed by sending a request for authentication to the user’s chosen identity provider.

If no Federation cookie is found at all, a passive authentication request is sent to the user’s chosen identity provider. A passive authentication request does not allow identity provider interaction with the user. When an affirmative response is received back from the identity provider, the user is redirected to the Identity Server Authentication Service. There, the user is granted a session token and redirected to the requested page. When the response from the identity provider is negative (for example, if the session has timed out), the user is sent to a common login page where he can choose to do a local login or Federation Single Sign-On.

Figure 5-3 illustrates the differences between the Pre-Login process path and the Identity Federation path.

System Flow

Figure 5-4 provides a high-level view of the system flow between various parties in a Liberty web services environment. In this figure, note the following:

The browser represents a user agent, a device used by an enterprise user.

The Service Provider also acts as a Web Service Consumer.

The Identity Provider hosts the Discovery Server.

The Personal Profile Service represents a Web Service Provider.

Figure 5-4 The interaction between Liberty II components.
Figure 5-4 provides a high-level view of the system flow between various parties in a Liberty web services environment.

This is what happens on the back end when an employee looks up a colleague’s phone number in an online corporate phone book:

The user's browser, Service Provider and Identity Provider complete the Federation Single-Sign-On process.

An assertion with an attribute statement containing the Discovery Service resource offering will be included in the ID-FF AuthnResponse. This information, is used by any client to contact Discovery Service.

The user's browser requests access to services hosted on the Web Service Consumer.

This requires contacting user's Personal Profile service.

The Web Service Consumer sends a discovery lookup query to the Discovery Service.

The Web Service Consumer determines user's discovery resource offering from the bootstrap Assertion obtained in Step 1, then sends a discovery lookup query to the Discovery Service to determine where the user's Personal Profile instance is hosted.

The Discovery service returns a discovery lookup response to the Web Service Consumer.

The lookup response contains the resource offering for the user's Personal Profile Service instance.

The Web Service Consumer sends a Data Services Template query to the SOAP end point of the Personal Profile Service instance.

The query asks for the user's personal profile attributes, such as home phone number. The required authentication mechanism specified in the Personal Profile Service resource offering must be followed.

The Personal Profile Service instance authenticates and validates authorization or policy, or both, for the requested user or Web Service Consumer, or for both.

If user interaction is required for some attributes, the Interaction Service will be invoked to query the user for consents or for attribute values. The Personal Profile Service instance returns a Data Services Template response to the Web Service Consumer after collecting all required data.

The Web Service Consumer processes the Personal Profile Service response, and then renders service pages containing the colleague’s contact information to the user's browser.

Previous Contents Index Next
Sun Java System Identity Server 2004Q2 Technical Overview