Sun Java System Access Manager 7.1 Technical Overview

Chapter 5 Federation, SAML, and Web Services

This chapter explains the concept of identity federation, and describes the role of the Federation feature in Access Manager. For detailed information about enabling or managing identity federation, or using the Federation Management APIs and SPIs, see the Sun Java System Access Manager 7.1 Federation and SAML Administration Guide.

This chapter includes the following topics:

Federating 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 tasks including reading and sending email, looking up information in the company phone book, searching internal databases, and submitting expense reports and other online forms. At home, he checks personal email, logs into an online news service, finalizes travel plans via a travel agent’s web site, and shops. Each time he accesses one of these services, he must log in and identify himself.

A local identity refers to the set of attributes or information that identify the user to a particular service provider. These attributes typically include a name and password, plus an email address, account number or other identifier. Most users have many local identities. For example, the individual in our scenario might log in at work using an employee number but, at home, he might log in to his travel agent as Joe Smith. He might use an account number to log in to the car rental agency he uses frequently, and he might log in to an airline using a frequent flyer number.

Identity federation allows a user to consolidate the many local identities he has configured among multiple service providers. With a federated identity, the individual can log in at one service provider 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 travel agency to book airline tickets and make hotel reservations. 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, knowing that his identity information is secure.

The Liberty Alliance Project

The Liberty Alliance Project develops and delivers specifications that enable federated network identity management and supporting web services. Using web redirection and open-source technologies such as SOAP and XML, they enable distributed, cross-domain interactions. The specifications include:

Liberty Identity Federation Framework
Liberty Identity Web Services Framework
Liberty Identity Services Interface Specifications
Schema Files and Service Definition Documents
Support Documents

An overview of these specifications as well as background information on the Liberty Alliance Project can be found in Chapter 1, Introduction to the Liberty Alliance Project, in Sun Java System Access Manager 7.1 Federation and SAML Administration Guide. The specifications themselves can be found on the Liberty Alliance Project web site.

How Federation Works

The goal of the Liberty Alliance Project specifications is to enable individuals and multiple organizations to easily conduct network transactions while protecting the individual’s identity. When organizations form a circle of trust, they agree to exchange user authentication information using web service technologies. A circle of trust must contain at least one identity provider, a service provider that maintains and manages identity information. It also includes multiple service providers that offer web-based services to users. Once a circle of trust is established, single sign-on is enabled between all the providers and users can federate their multiple identities.

In Access Manager, the circle of trust is referred to as an authentication domain. An authentication domain contains entities that are grouped together for the purpose of identity federation. A travel portal is a good example of an authentication domain. Typically, a travel portal is a web site designed to help you access various travel-related service providers from one location. The travel portal forms a partnership with each hotel, airline, and car rental agency displayed on its web site. The user registers with the travel portal which, in effect, is the authentication domain's identity provider. After logging in, the user looks for a flight using the airline service provider. After booking a flight, the user looks for a hotel using the accommodations service provider. This time, because of the agreements established among the travel portal partners, the airline web site shares the authentication information obtained earlier in the user's online session. The user moves from the hotel reservations web site to the airline reservations web site without having to re-authenticate. All of this is transparent to the user who must initially choose to unite his local identities. The following figure illustrates the travel portal example.

Figure 5–1 Federation Within a Travel Portal

This figure illustrates how a user's identity
can be shared among many businesses such as airlines, car rental agencies,
and hotels.

Note –

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. After account federation, when a user successfully authenticates with one service provider, he can access any of the his accounts within the authentication domain in a single session without having to reauthenticate.

The Web Services Stack

In Access Manager, the Federation framework enables the secure exchange of authentication and authorization information by providing an interface for creating, modifying, and deleting authentication domains and configuring service and identity providers (both remote and hosted types) as entities. Additionally, the implemented web services define a stack to support the Federation framework. The following figure illustrates the architecture of the web services stack and how a web service consumer communicates with the web service provider (Access Manager).

Figure 5–2 Web Services Architecture

This figure illustrates the web services architecture
in Access Manager.

Implemented Services

Access Manager includes the following web services based on the Liberty Alliance Project specifications:

Authentication Web Service: Provides authentication to a WSC, allowing the WSC to obtain security tokens for further interactions with other services at the same provider. Upon successful authentication, the final Simple Authentication and Security Layer (SASL) response contains the resource offering for the Discovery Service.
Discovery Service: A web service that allows a requesting entity, such as a service provider, to dynamically determine a principal's registered attribute provider. Typically, a service provider queries the Discovery Service, which responds by providing a resource offering that describes the requested attribute provider. The implementation of the Discovery Service includes Java and web-based interfaces.
SOAP Binding: A set of Java APIs used by the developer of a Liberty-enabled identity service. The APIs are used to send and receive identity-based messages using SOAP, an XML-based messaging protocol.
Liberty Personal Profile Service: A data service that supports storing and modifying a principal's identity attributes. Identity attributes might include information such as first name, last name, home address, and emergency contact information. The Liberty Personal Profile Service is queried or updated by a WSC acting on behalf of the principal.

Web Services Process

The following figure provides a high-level view of the process between the various components in the web services stack. In this example:

The web browser represents a user.
The service provider also acts as a web services consumer (WSC), invoking a web service on behalf of the user. The service provider relies on the identity provider for authentication.
The identity provider acts as an authentication provider by authenticating the user. It also acts as a trusted authority, issuing security tokens through the Discovery Service.
The web services provider (WSP) serves requests from web services clients such as the Liberty Personal Profile Service.

Figure 5–3 Web Services Stack Process

Illustration depicting the web services process
in Access Manager.

The following process assume that the user, the identity provider, and the service provider have already been federated.

The user attempts to access a resource hosted on the service provider server.
The service provider redirects the user to the identity provider for authentication.
The identity provider authenticates the user successfully and sends the single sign-on assertion to the requesting service provider.
The service provider verifies the assertion and the user is issued a session token.
The service provider redirects the user to the requested resource.
The user requests access to another service hosted on the WSC server.

For example, it might need that value of an attribute from the user’s Liberty Personal Profile Service.
The WSC sends a query to the Discovery Service to determine where the user’s Liberty Personal Profile Service instance is hosted.

The WSC bootstraps the Discovery Service with the resource offering from the assertion obtained earlier.
The Discovery Service returns a response to the WSC containing the endpoint for the user’s Liberty Personal Profile Service instance and a security token that the WSC can use to access it.
The WSC sends a query to the Liberty 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 Liberty Personal Profile Service resource offering must be followed.
The Liberty Personal Profile Service instance authenticates and validates authorization for the requested user or the WSC, or 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 Liberty Personal Profile Service instance returns a response to the WSC after collecting all required data.
The WSC processes the Liberty Personal Profile Service response, and renders the service pages containing the information.

For detailed information about all these components, see the Sun Java System Access Manager 7.1 Federation and SAML Administration Guide.

SAML Service

SAML defines an eXtensible Markup Language (XML) framework to achieve interoperability across different vendor platforms that provide SAML assertions. SAML is an XML framework for exchanging security information over the Internet. Access Manager SAML Service consists of a web service interface, a SAML core component, and a SAML framework that web services can connect to.

The Access Manager SAML Service enables the following functionality:

Users can authenticate against Access Manager and access trusted partner sites without having to reauthenticate. This single sign-on process independent of the process enabled by Access Manager user session management.
Access Manager acts as a policy decision point (PDP), allowing external applications to access user authorization information for the purpose of granting or denying access to their resources.
Access Manager acts as both an attribute authority (allowing trusted partner sites to query a subject’s attributes) and an authentication authority (allowing trusted partner sites to query a subject’s authentication information.)
Two parties in different security domains can validate each other for the purpose of performing business transactions.
Access Manager SAML APIs can be used to build Authentication, Authorization Decision and Attribute Assertions.
The Access Manager SAML Service provides pluggable XML-based digital signature signing and verifying.