Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java Systems Access Manager 6 2005Q1 Federation Management Guide 

Chapter 1
Introduction to the Liberty Alliance Project

Sun Java™ System Access Manager implements identity federation and Web services specifications defined by the Liberty Alliance Project. Before describing how this is accomplished, this appendix explains the concept of identity, identity services, the purpose of identity federation, and the role of the Liberty Alliance Project in creating identity-based solutions. It contains the following sections:


Overview

In 2001 Sun Microsystems joined with other major companies to form the Liberty Alliance Project (LAP). The goal of the LAP is to define standards for developing identity-based infrastructures, software, and Web services, and to promote adoption of these standards. The LAP does not deliver products or services; it defines frameworks to ensure interoperability between homogeneous products while respecting the privacy and security of identity data.


Note

If you are already familiar with the concepts and protocols developed by the Liberty Alliance Project, feel free to move on to Chapter 2, "Implementation of the Liberty Specifications" which begins to describe how these standards are integrated into the Sun Java System Access Manager product.


LAP Members

The members of the LAP include some of the world’s most recognized brand names, representing products, services and partnerships across a wide spectrum of consumer and business service providers. The consortium also includes government organizations and technology vendors. A complete listing of current members of the LAP can be found at http://www.projectliberty.org/membership/current_members.php.


Note

Only members of the Liberty Alliance Project are allowed to provide feedback on drafts of the specifications although any organization may implement them.


LAP Objectives

The specifications developed by the LAP enable individuals and organizations to securely conduct network transactions. More specifically, they:


The Concept of Identity

Identity can be defined as a set of information by which one person is definitively distinguished. In the real world, this information starts with a document that defines your name: a birth certificate. Over time, additional information further designates aspects of your identity:

Each of these distinct documents represents data that defines your identity specifically to the enterprise for which it was issued. The composite of this data constitutes an overall identity with each specific piece detailing a distinguishing characteristic.

Because the Internet is becoming the primary vehicle for the interactions represented by this identity-defining information, people are now creating identities online for the enterprises with which they interact. By defining a user identifier and password, an email address, your personal preferences (style of music, access device, opt-in/opt-out marketing decision, email frequency), and other information more specific to the particular business (social security number, credit records, bank account number, bill payment information, ship-to address), users distinguish themselves from others who use the enterprise’s services by creating this virtual identity. The virtual identity is referred to as a local identity because it is specific to the service provider for which it has been set. Considering the number of service providers for which you can define a local identity, it can make accessing each one time-consuming and frustrating. In addition, although most local identities are configured independently (and fragmented across the Internet), it might be useful to connect the information; for example, your local identity with a bank could be securely connected to your local identity with a retailer. Identity federation is the solution to this issue.


The Concept of Identity Federation

Consider the many times you might access service provider accounts in a single day; sending and receiving email, logging in to a news portal, checking bank balances, finalizing travel arrangements, bidding on auction items, accessing utility accounts, and shopping online are all possible services for which you would define an identity. Each time you want to access one of these services, you identify yourself to the provider by logging in. If you use all of these services, you’ve configured a multitude of separate accounts that you must log in to (and log out of) for access. This virtual identity phenomenom offers the opportunity to fashion a system for computer users to link their local identities. Identity federation allows the user to associate, connect or bind the various local identities they have configured for multiple service providers. The linked local identities, referred to as a federated identity, then allow the user to log in to one service provider site and click through to an affiliated service provider site without having to re-authenticate or re-establish their identity. This notion of single sign-on is an option to which the user must agree. The Liberty Alliance Project was implemented to define standards using open technologies, therefore encouraging an interoperational infrastructure among service providers, and identity federation among users.


Liberty Alliance Project Concepts

A number of concepts are derived from the LAP specifications (discussed in The Liberty Alliance Project Specifications). Definitions for them are provided here.

Account Federation (Identity Federation)

Account federation occurs when a user chooses to unite distinct service provider accounts with one or more identity provider accounts. Users retain the individual account information with each provider while, simultaneously, establishing a link that allows the exchange of authentication information between them.

Affiliation

An affiliation is a group of providers formed without regard to their particular authentication domain. It is formed and maintained by an affiliation owner. An affiliation document describes a group of providers collectively identified by their providerID. Members of an affiliation may invoke services either as a member of the affiliation (by virtue of their Affiliation ID) or individually (by virtue of their Provider ID).

Attribute Provider

An attribute provider is a web service that hosts attribute data. An example of an attribute provider would be an instance of the Personal Profile Service defined in Liberty Identity Service Interface Specifications.

Authentication Domain

A authentication domain is a group of service providers (with at least one identity provider) who agree to join together to exchange user authentication information using Liberty-enabled technologies. Once an authentication domain is established, single sign-on can be enabled amongst all membered providers. An authentication domain is sometimes referred to as a Circle Of Trust.


Note

An authentication domain is not a domain in the domain name system (DNS) sense of the word.


Circle Of Trust

See Authentication Domain.

Client

A client is actually the role any system entity assumes when making a request of another system entity. (In this scenario, the system entity of which the request is made is termed a Server.)

Common Domain

In an authentication domain having more than one identity provider, service providers need a way to determine which identity provider a principal uses. Because this function must work across any number of domain name system (DNS) domains, the Liberty approach is to create one domain common to all identity and service providers in the authentication domain. This predetermined domain is known as the common domain. Within the common domain, when a principal has been authenticated to a service provider, the identity provider writes a common domain cookie that stores the principal’s identity provider. Now, when the principal attempts to access another service provider within the authetnication domain, the service provider reads the common domain cookie and the request can be forwarded to the correct identity provider.

Defederation

See Federation Termination.

Federation Cookie

A federation cookie is a cookie implemented by Access Manager with the name fedCookie. It can have a value of either yes or no based on the principal’s federation status. The concept was developed for Access Manager, and is not a defined part of the LAP specifications. Information on how a federation cookie is used can be found in The Process of Federation of Chapter 3, "Federation Management."

Federated Identity

A federated identity refers to the amalgamation of the account information in all service providers accessed by one user (personal data, authentication information, buying habits and history, shopping preferences, etc.). The information is administered by the user yet, with the user’s consent, privilege to access the information is securely shared with their providers of choice.

Federation Termination

Users have the ability to terminate their federations. Federation termination (or defederation) results in the cancellation of affiliations established between the user’s identity provider and their federated service provider accounts.

Identity Provider

An identity provider is a service provider that specializes in providing authentication services. As the administrating service for authentication, identity providers also maintain and manage identity information. Authentication accomplished by an identity provider is honored by all service providers with whom it is affiliated. This term is used when defining an entity of this sort enabled by the ID-FF.

Identity Service

An identity service is a Web service that acts upon a resource to retrieve, update, or perform some action on data attributes related to a principal (an identity). An example of an identity service might be a corporate phone book or calendar service.

Liberty-enabled Client

A Liberty-enabled client is a client that has, or knows how to obtain, informatiuon about the identity provider that a principal will use to authenticate to a service provider.

Liberty-enabled Proxy

A Liberty-enabled proxy is an HTTP proxy that emulates a Liberty-enabled Client.

Name Identifier

To help preserve anonymity when identity information is exchanged between identity and service providers, an arbitrary name identifier is used. This pseudonym allows the providers to identify a principal without knowledge of the user’s actual identity. The name identifier has meaning only in the context of the relationship between partners.

Principal

A principal is an entity that can acquire a federated identity, that is capable of making decisions, and to which authenticated actions are done on its behalf. Examples of principals include an individual user, a group of individuals, a corporation, other legal entities, or a component of the Liberty architecture.

Pseudonym

See Name Identifier.

Receiver

A receiver is the role taken by a system entity when it receives a message sent by another system entity. (In this scenario, the system entity from which the message is received is termed a Sender.)

Resource Offering

In a discovery service, a resource offering defines associations between a piece of identity data and the service instance that provides access to it.

Sender

A sender is the role donned by a system entity when it constructs and sends a message to another system entity. (In this scenario, the system entity from which the message is received is termed a Receiver.)

Server

A server is actually the role any system entity assumes when providing a service in response to a request from another system entity. (In this scenario, the system entity from which the request is received is termed a Client.)


Note

In order to provide a service to clients, a server will often be both a Sender and a Receiver.


Service Provider

A service provider is a commercial or not-for-profit organization that offers web-based services to a principal. This broad category can include internet portals, retailers, transportation providers, financial institutions, entertainment companies, libraries, universities, and governmental agencies. This term is used when defining an entity of this sort enabled by the ID-FF.

Single Logout

A single logout occurs when a user logs out from an identity provider or a service provider. By logging out from one provider, they will effectively be logged out from all service providers or identity providers in that authentication domain.

Single Sign-on

Single sign-on is established when a user with a federated identity authenticates to an identity provider. Because they have previously opted-in for federation, they are now able to access affiliated service providers without having to re-authenticate.

Trusted Provider

A trusted provider is a generic term for one of a group of service and identity providers in an authentication domain. Users can transact and communicate with trusted providers in a secure environment.

Web Service Consumer

A Web service consumer invokes the operations a Web service provides by making a request to a Web service provider. This term is used when defining an entity of this sort enabled by the ID-WSF.

Web Service Provider

A Web service provider implements a Web service based on a request from a Web service consumer. It may run on the same Java™ virtual machine as the Web service consumer using it. This term is used when defining an entity of this sort enabled by the ID-WSF.


The Liberty Alliance Project Specifications

The LAP develops and delivers specifications that enable federated network identity management. Using Web redirection and open-source technologies like SOAP and XML, the LAP specifications enable distributed, cross-domain interactions. The LAP specifications are divided into three components:

Liberty Identity Federation Framework

The Liberty Identity Federation Framework (ID-FF) defines a set of protocols, bindings and profiles that provides a solution for identity federation, cross-domain authentication and session management. These definitions can be used to create a brand new identity management system or develop one in conjunction with legacy systems. The ID-FF is designed to work with heterogeneous platforms, all types of networking devices (including personal computers, mobile phones, and PDAs), and other emerging technologies. A scenario implementing these specifications includes the subjects illustrated in Figure 0-1 and defined beneath it.

Figure 0-1  Concepts of the ID-FF Specifications

An image illustrating the Liberty-based Federation Framework model.

The set of ID-FF protocols include:

Single Sign-on and Federation Protocol

The Single Sign-on and Federation Protocol defines a request/response protocol by which a principal is able to authenticate to a service provider, and federate (or link) their identities. A service provider issues a request for authentication to an identity provider. The identity provider responds with a message containing authentication information, or an artifact that points to authentication information which can then be de-referenced into authentication information. Additionally, the identity provider can federate the principal’s identity (configured at the identity provider level) with the principal’s identity (configured at the service provider level).


Note

Under certain conditions, an identity provider may issue an authentication response to a service provider without having received an authentication request.


The Single Sign-on and Federation Protocol also defines controls that allow for the following behaviors:

Account federation.     Principals can choose to federate their identity at the identity provider with their identity at the service provider.

Authentication context.     Service providers can choose the type and level of authentication that should be used when the principal logs in.

Authentication credentials.     Principals may be prompted for credentials at the behest of the service provider.

Account handle.     An identity provider can issue an anonymous and temporary identifier to refer to a particular principal during communication with a service provider. This identifier is used to obtain information for or about principals (with their permission) during federation.


Caution

This account handle is generated by the identity provider during federation unlike the handle that can be generated by the service provider after federation using the Name Registration Protocol.


Dynamic proxying.     An identity provider that is asked to authenticate a principal it believes has already authenticated via another identity provider may make an authentication request on behalf of the requesting provider to the authenticating identity provider.

Identity provider introduction.     When an authentication domain has more than one identity provider, a service provider can use this feature to discover which identity provider a principal is using.

Message exchange profiles.     The authentication request defines how messages are exchanged between identity providers and service providers. The particular transfer and messaging protocol (HTTP, SOAP, etc.) used in the exchange are specified in profiles. Two of them are:

Name Registration Protocol

The Name Registration Protocol is an optional-use protocol used by the service provider to create its own opaque handle to identify a principal when communicating with the identity provider.


Caution

This handle is not related to the opaque handle generated by the identity provider during federation as defined in the Single Sign-on and Federation Protocol. The Name Registration Protocol can, though, be used by the identity provider to change the opaque handle they registered with the service provider during initial federation.


Federation Termination Protocol

The Federation Termination Protocol defines how one provider (of either type) notifies another provider (of either type) when a principal has terminated their identity federation. The notification is in the form of a one-way, asynchronous message which states that either the service provider will no longer accept authentication information regarding the particular user, or the identity provider will no longer provide authentication information regarding the particular user.

Single Log-out Protocol

The Single Log-out Protocol defines how providers will notify each other of logout events. This message exchange protocol is used to terminate all sessions when a log out occurs at the service provider or identity provider level. The particular transfer and messaging protocol (HTTP, SOAP, etc.) used in the exchange are specified in profiles. Two of them are:

Name Identifier Mapping Protocol

The Name Identifier Mapping Protocol defines how service providers can obtain name identifiers for a principal that has federated in the name space of a different service provider. This can be accomplished by querying an identity provider that has federated the user with both service providers. This allows the requesting provider to communicate with the other service provider without an identity federation for the principal between them.

Additional ID-FF Documents

Additional information explaining the ID-FF specifications can be found in the documents detailed in Table 0-1.

Table 0-1  Additional Help with the ID-FF

Name of Document

Overview

Liberty ID-FF 1.2 Architecture Overview

http://www.projectliberty.org/specs/liberty-idff-arch-overview-v1.2.pdf

The Architecture Overview provides an architectural description of the ID--FF framework as well as policy, security and technical notes.

Liberty ID-FF 1.2 Protocols and Schema Specification

http://www.projectliberty.org/specs/draft-liberty-idff-protocols-schema-1.2-errata-v1.0.pdf

The Protocols and Schema Specification provide the abstract Liberty protocols for Identity Federation, Single Sign-on, Name Registration, Federation Termination, and Single Log-out.

Liberty ID-FF 1.2 Implementation Guidelines

http://www.projectliberty.org/specs/liberty-idff-guidelines-v1.2.pdf

The Implementation Guidelines provide guidance and checklists for implementing a Liberty-enabled environment using the ID-FF Specifications.

Liberty ID-FF 1.2 Static Conformance Requirements

http://www.projectliberty.org/specs/liberty-idff-1.2-scr-v1.0.pdf

The Static Conformance Requirements define what features are mandatory and optional for implementations conforming to this version of the ID-FF Specifications.

Liberty Identity Web Services Framework

The ID-FF defines how to implement single sign-on and identity federation to solve problems related to network identity. The Liberty Identity Web Services Framework (ID-WSF) builds upon this by providing specifications to build Web services that retrieve, update, or perform an action on, identity data in a federated network environment. The specifications outline the technical components necessary to build Web services that interoperate with identity data, such as a calendar service, a wallet service, or an alert service. A scenario implementing these specifications includes the subjects defined below.

Web services are the basis of distributed computing across the Internet. A WSC locates a Web service and invokes the operations it provides. The WSP is the application implementing a Web service; it can be on the same Java™ virtual machine as the WSC, or it can be thousands of miles away. When a WSC needs to retrieve identity attributes from a WSP, it must first contact a discovery service to locate where the particular attributes are stored. When this information is returned, the WSC then contacts the WSP (for example, a personal profile service) to retrieve the necessary attributes.


Note

More information on the WSC/WSP process of the Liberty ID-WSF can be found in Discovery Service Process of Chapter 6, "Discovery Service."


The defined features of the ID-WSF include:

SOAP Binding Specification

The SOAP Binding Specification details a transport layer for handling SOAP messages. Among other features, it defines SOAP header blocks and processing rules enabling the invocation of identity services via SOAP requests and responses. It also specifies how to configure messages for optimum message correlation (assuring the relationship between a SOAP request and its response), consent claims (permission to perform a certain action), and usage directives (data handling policies).

Discovery Service Specification

The Discovery Service Specification defines a framework that enables a client to locate the appropriate Web service for retrieving, updating, or modifying a particular piece of identity data. Typically, there are one or more services on a network that allow entities to perform an action on identity data. To keep track of these services or to know which can be trusted, clients require a discovery service, essentially a Web service interface for a registry of resource offerings. A resource offering defines an association between a piece of identity data and the service instance that provides access to it. A common use case is when a personal profile, or calendar data are placed within a discovery resource so that the data can be located by other entities.

Security Mechanisms Specification

The Security Mechanisms Specification describes the requirements for securing authorization decisions sent for the discovery, and use, of identity services. The specified mechanisms provide for authentication, signing and encryption operations to ensure integrity and confidentiality of the messages.

Data Services Template Specification

The Data Services Template Specification defines how to query and modify identity data attributes stored in a data service (a Web service that holds data). The specification also provides some common attributes for data services.

Interaction Service Specification

The Interaction Service Specification details communication protocols for identity services to obtain permission from a principal (or someone who owns a resource on behalf of that principal) that allows the service to share their identity data with requesting services.

Authentication Service Specification

The Authentication Service Specification defines how to authenticate parties communicating via SOAP-based messages. It leverages widely used authentication services and mechanisms, and facilitates selection of these services and mechanisms at deployment time. The specification defines:

The specification also defines an identity-based authentication security token service, complementing the more general security token service defined by the Discovery Service Specification.

Client Profiles for Liberty-enabled User Agents or Devices

The Client Profiles for Liberty-enabled User Agents or Devices describes the requirements for Liberty-enabled clients interacting with the SOAP-based Authentication Service. These profiles can enable browsers to perform an active role in transactions, in addition to the functions of a standard browser.

Additional ID-WSF Documents

Additional information explaining the ID-WSF specifications can be found in the documents detailed in Table 0-2.

Table 0-2  Additional Help with the ID-WSF

Name of Document

Overview

Liberty ID-WSF Web Services Framework Overview

http://www.projectliberty.org/specs/liberty-idwsf-overview-v1.0.pdf

The Web Services Framework Overview provides an architectural description of the ID-WSF framework including basic usage scenarios. It also highlights how the ID-WSF interacts with an identity management framework (such as the ID-FF).

Liberty ID-WSF Security and Privacy Overview

http://www.projectliberty.org/specs/liberty-idwsf-security-privacy-overview-v1.0.pdf

The Security and Privacy Overview provides an overview of security and privacy issues in ID-WSF.

Liberty Identity Service Interface Specifications

The Liberty Identity Service Interface Specifications (ID-SIS) contain the following specifications for building these identity-based Web services:

Personal Profile Service

The Personal Profile Service defines an identity-based Web service that keeps, updates, and offers identity data regarding a user. The Personal Profile Service is characterized by the ability to query and update attribute data and incorporates mechanisms for access control and conveying data validation information and usage directives from other specifications. 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

The Employee Profile Service defines an identity-based web service which keeps, updates, and offers profile information regarding a user’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 Documents

There are many other support documents in the LAP specifications. They include a metadata service protocol, reverse HTTP bindings, a glossary, and schema files. More information can be found at the LAP Web site or, more specifically, at http://www.projectliberty.org/resources/specifications.php#box4.


Deploying a Liberty-based System

This section details a few things to consider when building a successful Liberty-based implementation.

Size Up Your IT Staff

Although the LAP specifications are aimed at large organizations, small and medium-sized companies with a saavy IT staff can also roll out a federated identity system. The specifications are complicated and cross several domains of expertise (Web services development, XML, networking, and security).

Clean Your Directory Data

The LAP specifications do not specify where you store identity data; they are more concerned with it’s accuracy. Purge your data store of old identity profiles, consolidate multiple (or delete duplicated) identity profiles, and ensure privileges are assigned correctly.


Caution

Identity Providers should enforce strong passwords. A stolen identity can be abused across multiple sites in a federated system.


Draft Business Agreements

The LAP specifications assume pre-existing trust relationships between members in a Circle of Trust. This trust is defined through business arrangements or contracts that describe the technical, operational, and legal responsibilities of each party and the consequences for failing in them. When defined, a Liberty trust relationship means that one organization trusts another’s user authentication decisions. That trust among members lets a user log in at one site and access another site as well: single sign-on (SSO). Ensure that these agreements are in play before going live with a Liberty-compliant system.

Liberty-compliant Technology

At the minimum, a Liberty-compliant identity server is needed to process Liberty-based requests and responses. Chapter 2, "Implementation of the Liberty Specifications" begins our discussion of Sun Microsystems’ implementation of the LAP specifications, the Sun Java™ System Access Manager.



Previous      Contents      Index      Next     


Part No: 817-7648.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.