Part I The Liberty Alliance Project Specifications and Access Manager

• Chapter 1, Introduction to the Liberty Alliance Project

• Chapter 2, Implementation of the Liberty Alliance Project Specifications

Chapter 1 Introduction to the Liberty Alliance Project

Sun Java™ System Access Manager implements identity federation, single sign-on (SSO), and web services specifications defined by the Liberty Alliance Project. This introductory chapter explains concepts used in the specifications, and the role of the Liberty Alliance Project in creating identity-based solutions. It covers the following topics:

• Overview of the Liberty Alliance Project

• Concept of Identity

• Concept of Federation

• Concept of Trust

• Liberty Alliance Project Terms

• Liberty Alliance Project Specifications

Overview of the Liberty Alliance Project

In 2001 Sun Microsystems joined with other major companies to form the Liberty Alliance Project. The goals were to define standards for developing identity-based infrastructures, software, and web services, and to promote adoption of these standards. The Liberty Alliance Project does not deliver products or services. It defines frameworks to ensure interoperability between homogeneous products while respecting the privacy and security of identity data. This section contains the following information:

• Members of the Liberty Alliance Project

• Objectives of the Liberty Alliance Project Specifications

If you are already familiar with the concepts and protocols developed by the Liberty Alliance Project, go to Chapter 2, Implementation of the Liberty Alliance Project Specifications for information on how these standards are integrated into Access Manager.

Members of the Liberty Alliance Project

The members of the Liberty Alliance Project include some of the world’s most recognized companies, representing products, services and partnerships across a wide spectrum of consumer and business service providers. Members also include government organizations and technology vendors. For more information regarding membership (and a complete listing of current members), see the Liberty Alliance Project web site.

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

Objectives of the Liberty Alliance Project Specifications

The specifications developed by the Liberty Alliance Project enable individuals and organizations to securely conduct network transactions. The main objectives include:

• Serve as open standards for federated identity management and web services.

• Support and promote permission-based sharing of personal identity attributes.

• Provide a standard for SSO that includes decentralized authentication and authorization for multiple providers.

• Create an open network identity infrastructure that supports all current and emerging user agents (also referred to as browsers or wireless browsers).

• Enable consumers to protect their network identity information.

Concept of Identity

In one dictionary, identity is defined as ”a set of information by which one person is definitively distinguished”. This information begins with a document that corroborates a person's name: a birth certificate. Over time, additional information further designates aspects of identity:

• An address

• A telephone number

• One or more diplomas

• A driver’s license

• A passport

• Financial institution accounts

• Medical records

• Insurance statements

• Employment records

• Magazine subscriptions

• Utility bills

Each of these individual documents represents data that defines a person's identity as it relates to the enterprise for which the document was defined. The composite of this data constitutes an overall identity with each specific piece providing a distinguishing characteristic.

Because the Internet is becoming the primary vehicle for the types of interactions represented by this identity-defining information, people are now creating online identities specific to the businesses with which they interact. By defining a user identifier and password, an email address, personal preferences (such as style of music, or opt-in/opt-out marketing decisions) and other information more specific to the particular business (a bank account number or ship-to address), users distinguish themselves from others who use the enterprise’s services. This distinguishing information 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, accessing each one can be a time-consuming and frustrating experiencing. In addition, although most local identities are configured independently (and fragmented across the Internet), it might be useful to connect the information. For example, a user's local identity with a bank could be securely connected to the same user's local identity with a retailer. Federation addresses this issue.

Concept of Federation

Federation is defined as ”an association formed by merging several groups or parties”. In the Liberty Alliance Project specifications, federation encompasses both identity federation and provider federation.

• Identity Federation

• Provider Federation

Identity Federation

Federation, as it has evolved with regard to individual users and the World Wide Web, begins with the notion of identity. (See Concept of Identity.) Sending and receiving email, checking bank balances, finalizing travel arrangements, accessing utility accounts, and shopping are just a few online services for which a user might define an identity. If a user accesses all of these services, many different identity accounts have been configured. This virtual phenomenon offers an opportunity to fashion a system for users to federate these identities.

Identity federation allows the user to link, connect, or bind the local identities that have been created for each service provider (a networked entity that provides services to other entities). The linked local identities, referred to as a federated identity, allow the user to log in to one service provider site and click through to an affiliated service provider without having to reauthenticate or reestablish identity.

Provider Federation

The concept of federation, as defined by the Liberty Alliance Project, begins with a ”circle of trust.” A circle of trust is a group of service providers who contractually agree to exchange authentication information using a Liberty-enabled architecture. Each circle of trust must also include at least one identity provider, a service provider that maintains and manages identity data, and provides authentication services.

The establishment of contractual agreements between providers is beyond the scope of this guide. See Concept of Trust for an overview.

After the contracts and policies defining a circle of trust are in place, the specific protocols, profiles, endpoints, and security mechanisms being used in the deployment are collected into a metadata document that is exchanged amongst the members of the circle of trust. Access Manager provides the tools necessary to integrate the metadata and enable the circle of trust, technologically, as an authentication domain. Authentication within this virtual federation is honored by all membered providers of the authentication domain. For more information, see Authentication Domain.

Concept of Trust

The Liberty Alliance Project specifications assume existing trust relationships between members in a circle of trust. This trust is usually defined through business arrangements or contracts that describe the technical, operational, and legal responsibilities of each party and the consequences for not completing them. When defined, a trust relationship allows one organization to trust the user authentication and authorization decisions of another organization. This trust then enables a user to log in to one site and, if desired, access a trusted site without reauthentication.

Ensure that these trust agreements are in force before going live with a Liberty-compliant system. The Liberty Alliance Project has created a support document for helping to establish these arrangements. The Liberty Trust Model Guidelines document is located on the Support Documents and Utility Schema Files page on the Liberty Alliance Project web site.

Liberty Alliance Project Terms

Many of the concepts defined in this section are derived from the specifications discussed in Liberty Alliance Project Specifications.

• Account Federation

• Affiliation

• Attribute Provider

• Authentication Context

• Authentication Domain

• Binding

• Circle of Trust

• Client

• Common Domain

• Defederation

• Federation

• Federation Cookie

• Federated Identity

• Federation Termination

• Identity

• Identity Federation

• Identity Provider

• Identity Service

• Liberty-Enabled Client

• Liberty-Enabled Proxy

• Name Identifier

• Principal

• Profile

• Protocol

• Provider Federation

• Pseudonym

• Receiver

• Resource Offering

• Sender

• Server

• Service Provider

• Single Logout

• Single Sign-On

• Trusted Provider

• Web Service Consumer

• Web Service Provider

Account Federation

See Identity Federation.

Affiliation

An affiliation is a group of providers formed without regard to their configured authentication domains. An affiliation is formed and maintained by an affiliation owner. 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). An affiliation document describes a group of providers. See Entities for more information.

Attribute Provider

An attribute provider is a web service that hosts attribute data. The Access Manager Liberty Personal Profile Service data service is an example of an attribute provider. For more information, see Chapter 7, Data Services.

Authentication Context

Authentication context refers to information added to a SAML Authentication Assertion regarding details of the technology used for the actual authentication action. This information might include the method of authentication (for example, HTTP Basic or Safeword), the process followed in the issuance of the identity (for example, web self-registration), and any other characteristics that may be relevant to the service provider consuming the assertion. The following code sample describes a user having authenticated with a password over an SSL-protected session.

Example 1–1 XML Code Sample Defining Authentication Context

<?xml version="1.0" encoding="UTF-8" ?>
<AuthenticationContextStatement>
            <AuthenticationMethod>
                <PrincipalAuthenticationMethod>
                   <Password>
                      <Length min="3"/>
                   </Password>
                </PrincipalAuthenticationMethod>
                <AuthenticatorTransportProtocol>
                   <SSL/>
                </AuthenticatorTransportProtocol>
            </AuthenticationMethod>
<AuthenticationContextStatement>

More information is in Authentication and Authentication Context.

Authentication Domain

An authentication domain is a federation of service providers (with at least one identity provider) that is configured using Access Manager.

An authentication domain is not a domain in the Domain Name System (DNS) sense of the word.

Before an authentication domain can be configured, the service providers must contractually agree to exchange authentication information using the Liberty Alliance Project specifications. After this circle of trust is established, an authentication domain can be configured using Access Manager and single sign-on can be enabled. Simply put, an authentication domain is the term used by Access Manager when configuring a circle of trust. See Concept of Trust for related information.

Binding

A binding describes how to integrate request and response messages into a transmission protocol. See Profile and Protocol for related information.

Circle of Trust

See Provider Federation.

Client

A client is the role that any system entity assumes when making a request of another system entity. In this scenario, the system entity to which the request is made is called a server as discussed in Server.

Common Domain

If an authentication domain has more than one identity provider, the service providers need a way to determine which identity provider is used by the principal (as discussed in Principal). Because this function must work across any number of DNS domains, the Liberty approach is to create one domain that is common to all identity and service providers in the authentication domain. This predetermined domain is called 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. When the principal attempts to access another service provider within the authentication domain, the service provider reads the common domain cookie and the request is forwarded to the correct identity provider. See Chapter 4, Common Domain Services for Federation Management for more information.

Defederation

See Federation Termination.

Federation

See Concept of Federation.

Federation Cookie

A federation cookie called fedCookie is implemented by Access Manager. It can have a value of yes or no, based on the principal’s federation status. For information on how a federation cookie is used, see Process of Federation in Chapter 3, Federation.

The concept of a federation cookie was developed for Access Manager and is not a defined part of the Liberty Alliance Project specifications. The definition is placed here for information only.

Federated Identity

A federated identity refers to a user's consolidated local identities. The user must choose to federate the separate identities that they have configured with multiple service providers. Although federated, the local identities are still administered by the user, but they can be securely shared between the service providers for which they were defined.

Federation Termination

Users can terminate their federations. Federation termination (or defederation) cancels identity federations established between the user’s identity provider and service provider accounts.

Identity

See Concept of Identity.

Identity Federation

Identity federation occurs when a user chooses to unite distinct service provider accounts with one or more identity provider accounts. A user retains the individual account information with each provider while simultaneously establishing a link that allows the exchange of authentication information between them. For more information, see Concept of Federation.

Identity Provider

An identity provider is a service provider that specializes in providing authentication services. As the administrating service for authentication, an identity provider also maintains and manages identity information. Authentication by an identity provider is honored by all service providers with whom the identity provider is affiliated. This term is used when defining an entity of this sort specific to the Liberty Identity Federation Framework as discussed in Liberty Identity Federation Framework.

Identity Service

An identity service (also referred to as a data service or an attribute provider) is a web service that acts on a resource to retrieve, update, or perform some action on data attributes related to a principal (an identity). For example, an identity service might be a corporate phone book or calendar service. For more information, see Chapter 7, Data Services.

Liberty-Enabled Client

A Liberty-enabled client is a client that has, or knows how to obtain, information 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 providers and service providers, an arbitrary name identifier is used. A name identifier is a randomly generated character string that is assigned to a principal and used to facilitate account linking at the identity provider and service provider sites. This pseudonym allows all providers to identify a principal without knowing the user’s actual identity. The name identifier has meaning only in the context of the relationship between providers.

Principal

A principal is an entity that can acquire a federated identity, that is capable of making decisions, and has authenticated actions 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.

Profile

A profile defines the HTTP exchanges required to transfer XML requests and responses between providers. See Binding and Protocol for related information.

Protocol

A protocol is an agreed-upon set of rules for formatting data to be transmitted between two or more devices. XML schemas define the syntax for request and response messages that are typically embedded into other structures for transport. Among other things, a protocol can determine:

• The type of error checking to be used.

• Data compression method, if any.

• How the sending device will indicate that it has finished sending a message.

• How the receiving device will indicate that it has received a message.

See Binding and Profile for related information.

Provider Federation

See Concept of Federation.

Pseudonym

See Name Identifier.

Receiver

A receiver is the role of 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 called a sender as discussed in 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. See Chapter 8, Discovery Service.

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 called a receiver as discussed in Receiver.

Server

A server is the role that 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 called a client as discussed in Client.

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 specific to the Liberty Identity Federation Framework as discussed in Liberty Identity Federation Framework.

Single Logout

A single logout occurs when a user logs out of an identity provider or a service provider. By logging out of one provider, the user is logged out of 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. If the user has previously opted-in for federation, access to affiliated service providers is available without having to reestablish identity.

Trusted Provider

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

Web Service Consumer

A web service consumer invokes the operations that a web service provides by making a request to a web service provider. This term is used when defining an entity of this sort specific to the Liberty Identity Web Services Framework as discussed in Liberty Identity Web Services Framework.

Web Service Provider

A web service provider implements a web service based on a request from a web service consumer. This term is used when defining an entity of this sort specific to the Liberty Identity Web Services Framework as discussed in Liberty Identity Web Services Framework.

A web service provider may run on the same Java virtual machine as the web service consumer that is using it.

Liberty Alliance Project Specifications

The Liberty Alliance Project develops and delivers specifications that enable federated network identity management. Using web redirection and open-source technologies such as SOAP and XML, they enable distributed, cross-domain interactions. The specifications are divided into the following components:

• Liberty Identity Federation Framework

• Liberty Identity Web Services Framework

• Liberty Identity Service Interface Specifications

• Schema Files and Service Definition Documents

• Support Documents

Liberty Identity Federation Framework

The Liberty Identity Federation Framework (Liberty ID-FF) defines a set of protocols, bindings, and profiles that provides a solution for identity federation, cross-domain authentication, and session management. This framework can be used to create a new identity management system or to develop one in conjunction with legacy systems. This section contains information regarding the Liberty ID-FF.

• The Liberty ID-FF Model

• The Liberty ID-FF Convergence

• Liberty ID-FF Protocols and Schema

• Liberty ID-FF Bindings and Profiles

• Additional Liberty ID-FF Documents

More detailed information about the Liberty ID-FF 1.2 specifications can be found on the Liberty Alliance Project web site at the Liberty Alliance ID-FF 1.2 Specifications page.

The Liberty ID-FF Model

The Liberty ID-FF is designed to work with heterogeneous platforms, various networking devices (including personal computers, mobile phones, and personal digital assistants), and emerging technologies. The following figure shows the subjects involved in a Liberty ID-FF implementation.

Figure 1–1 Subjects Involved in a Liberty ID-FF Implementation

• A principal can have a defined local identity with more than one provider, and it has the option to federate the local identities. The principal might be an individual user, a group of individuals, a corporation, or a component of the Liberty architecture.

• A service provider is a commercial or not-for-profit organization that offers a web-based service such as a news portal, a financial repository, or retail outlet.

• An identity provider is a service provider that stores identity profiles and offers incentives to other service providers for the prerogative of federating their user identities. Identity providers might also offer services above and beyond those related to identity profile storage.

• To support identity federation, all service providers and identity providers must join together into a circle of trust. A circle of trust must contain at least one identity provider and at least two service providers. (One organization may be both an identity provider and a service provider.) Providers in a circle of trust must first write operational agreements to define their relationships. An operational agreement is a contract between organizations that defines how the circle will work. For more information, see Concept of Trust.

The Liberty ID-FF Convergence

Up to version 1.1, the Liberty ID-FF was developed using the SAML 1.0 specification. The Liberty ID-FF 1.2 was then developed using the SAML 1.1 specification. Following the release of version 1.2, the Liberty ID-FF was reintroduced into the SAML 2.0 specification. Additionally, SAML 2.0 adds components of the Shibboleth initiative. Going forward, SAML 2.0 will be the basis on which the Liberty Alliance Project builds additional federated identity applications (such as web service-enabled permissions-based attribute sharing). As such, SAML 2.0 is a critical step towards full convergence of federated identity standards. The following diagram illustrates the convergence history of SAML and the Liberty ID-FF.

Figure 1–2 Liberty ID-FF and SAML Convergence

For more information on this convergence (including how the Shibboleth Project was also integrated), see the Federation section of Strategic Initiatives on the Liberty Alliance Project web site.

Liberty ID-FF Protocols and Schema

The Liberty ID-FF Protocols and Schema Specifications defines transmission formats for the following functions:

• Single Sign-On and Federation Protocol

• Name Registration Protocol

• Federation Termination Notification Protocol

• Single Logout Protocol

• Name Identifier Mapping Protocol

Following are short explanations of each protocol. More detailed information can be found in the Liberty ID-FF Protocols and Schema Specifications.

Single Sign-On and Federation Protocol

The Single Sign-On and Federation Protocol defines the rules for request and response messages with which a principal is able to authenticate to one or more service providers and federate (or link) configured identities. When a principal attempts to access a service provider resource, the service provider issues a request for authentication to the principal's identity provider. The identity provider responds with a message that contains authentication information, or an artifact that points to authentication information.

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 elements for inclusion in the request and response that control the following behaviors:

• Account federation. A principal can choose to federate a configured identity at the identity provider site with a configured identity at the service provider site.

• Account handle. An identity provider can issue an anonymous, temporary identifier to refer to a particular principal during communication with a service provider. This identifier is used to obtain information for or about the principal during federation (with the principal's consent). The account handle is generated by the identity provider during federation.

  ---

  Note –

  This account handle is not to be confused with the handle that can be generated by the service provider after federation using the Name Registration Protocol as discussed in Name Registration Protocol.

  ---

• Affiliation federation. Federation based on group affiliation can be enabled in an authentication request. If enabled, it indicates that the requester is acting as a member of the specified affiliation group. Federations are then established and resolved based on the affiliation, not the requesting provider. The process allows for a unique identifier that represents the affiliation.

• Authentication context. A service provider can choose the type and level of authentication that should be used when a principal logs in.

• Authentication credentials. A principal can be prompted to authenticate with a user name and password, for example, at the behest of the service provider.

• Dynamic identity provider proxying. One identity provider might be asked to authenticate a principal that has already been authenticated by a second identity provider. In this case, the first identity provider may request authentication information from the second identity provider on behalf of the service provider. Proxy behavior can be controlled by indicating a list of preferred identity providers, and a value that defines the maximum number of proxy steps that can be taken. Proxy behavior is defined locally by the proxying identity provider, although a service provider controls whether or not to proxy. For more information, see Dynamic Identity Provider Proxying.

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

• Message exchange. The authentication request defines how messages are exchanged between identity providers and service providers. The particular transfer and messaging protocol used in the exchange (such as HTTP or SOAP) are specified in profiles defined in the Liberty ID-FF Bindings and Profiles Specification. Two of these profiles are:

  • The Liberty Artifact profile relies on Security Assertion Markup Language (SAML) artifacts and assertions to relay authentication information.

  • The Liberty Browser POST profile relies on an HTML form to communicate authentication information between providers.

  See Liberty ID-FF Bindings and Profiles for more information.

• One-time federation. The ability to federate for one session only can be enabled in an authentication request. This feature is useful for service providers with no user accounts, for principals who want to act anonymously, or for dynamically created user accounts. It allows for one-time federation, rather than a one-time name identifier for a session.

Name Registration Protocol

The optional Name Registration Protocol defines the request and response messages a service provider would use to create its own opaque handle to identify a principal when communicating with the identity provider. This registration would occur after federation has been accomplished. After the service provider registers this new handle, subsequent communications with the identity provider would use this identifier rather than the identifier originally defined by the identity provider.

The handle discussed in this section is not related to the opaque handle that is generated by the identity provider during federation as defined in Single Sign-On and Federation Protocol. The Name Registration Protocol can, however, be used by the identity provider to change the opaque handle that it registered with the service provider during initial federation.

Federation Termination Notification Protocol

The Federation Termination Notification Protocol defines a one-way message that one provider would use to notify another provider when a principal has terminated identity federation. The message is asynchronous and states one of the following:

• The service provider will no longer accept authentication information regarding the particular user.

• The identity provider will no longer provide authentication information regarding the particular user.

Single Logout Protocol

The Single Logout Protocol defines the request and response messages that providers would exchange when notifying each other of logout events. This exchange would terminate all sessions when a logout occurs at either the service provider or the identity provider.

Name Identifier Mapping Protocol

The Name Identifier Mapping Protocol defines the request and response messages that one service provider can use to communicate with a second service provider to obtain the name identifier assigned to a principal federated in the name space of the second service provider. This would be used when a principal authenticated to one service provider requests access to a second service provider site with which it also has an identity federation relationship. The protocol allows the second service provider to communicate with the first service provider about the principal even though no identity federation for the principal exists between the two service providers.

Liberty ID-FF Bindings and Profiles

The Liberty ID-FF Bindings and Profiles Specification defines the bindings and profiles for the request and response messages explained in Liberty ID-FF Protocols and Schema. A binding describes how to integrate request and response messages into a transmission protocol. Currently, this specification defines only a SOAP binding. A profile defines the HTTP exchanges required to transfer the requests and responses between providers. The defined profiles are:

• Single Sign-on and Federation

• Name Identifier Registration

• Federation Termination Notification

• Single Logout

• Identity Provider Introduction

• Name Identifier Mapping

• Name Identifier Encryption

For more information about these profiles and transmission of requests and responses in general, see the Liberty ID-FF Bindings and Profiles Specification.

Additional Liberty ID-FF Documents

For additional information about the Liberty ID-FF specifications, the following documents are available on the Liberty ID-FF 1.2 specification page.

• Liberty ID-FF Architecture Overview

  Provides an architectural description of the Liberty ID-FF framework as well as policy, security, and technical notes.

• Liberty ID-FF Guidelines

  Provides guidance and checklists for implementing a Liberty-enabled environment using the Liberty ID-FF specifications.

• Liberty ID-FF Static Conformance Requirements

  Defines what features are mandatory and optional for implementations conforming to this version of the Liberty ID-FF specifications.

Liberty Identity Web Services Framework

The Liberty 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 (Liberty ID-WSF) builds on this by providing specifications for identity-based web services to work in tandem with the Liberty ID-FF. (An identity-based web service, or identity service, is a type of web service that acts upon a resource to retrieve information about an identity, update information about an identity, or perform some action for the benefit of an identity.) The Liberty ID-WSF can be used to develop web services that retrieve, update, or perform an action on identity data in a federated network environment using a SOAP-based invocation. The web services include, among others, a calendar service, a wallet service, and an alert service. A scenario that implements these specifications includes the following subjects:

• A web service consumer (WSC) invokes the functions provided by a web service by making a request to the web service's provider.

• A web service provider (WSP) implements a web service based on a request from a WSC.

For more information about the process between a WSC and WSP, see Discovery Service Process.

The following sections contain brief explanations of the Liberty ID-WSF 1.1 specifications.

• SOAP Binding Specification

• Discovery Service Specification

• Security Mechanisms Specification

• Data Services Template Specification

• Interaction Service Specification

• Authentication Service Specification

• Client Profiles Specification

• Additional Liberty ID-WSF Documents

More detailed information about the Liberty ID-WSF specifications can be found on the Liberty Alliance Project web site.

SOAP Binding Specification

The Liberty ID-WSF SOAP Binding Specification provides a transport layer framework for handling the request and response messages used by the Liberty ID-WSF services. It defines a mapping for the messages onto SOAP, an extensible XML-based messaging protocol by specifying, for example, how to:

• Correlate a particular SOAP request with its response.

• Indicate that Principal consent was obtained to carry out a given operation.

• Express additional context for a request.

For more information, see the Liberty ID-WSF SOAP Binding Specification.

Discovery Service Specification

The Liberty ID-WSF 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 access to a discovery service. A discovery service is an identity service that acts as a registry of resource offerings. A resource offering defines an association between a particular piece of identity data and the instance of a web service that provides access to the data. With access to the discovery service, the client is able to discover which web service must be contacted to then access the desired identity data. A common use case is when personal profile or calendar data is placed within a resource offering so that the data can be located by other entities. For more information, see the Liberty ID-WSF Discovery Service Specification.

Security Mechanisms Specification

To access an identity service, an entity must interact with a discovery service to locate the appropriate identity service as well as the specific identity service instance that exposes the resource. The Liberty ID-WSF Security Mechanisms Specification describes mechanisms (providing authentication, signing and encryption operations) that can be used to ensure the integrity and confidentiality of the authorization messages exchanged when evaluating the entity's authorization to access the discovery service and identity service instance. These mechanisms consider:

• Authentication of the sender.

• Proxy rights for a third party to make a request as identity services may be accessed directly or through the assistance of an intermediary.

• Authentication of the response.

• Authentication context and session status of the interacting entity.

• Authorization of invocation identity to access service or resource.

For more information, see the Liberty ID-WSF Security Mechanisms Specification.

Data Services Template Specification

A data service is a web service that supports the query and modification of identity data. (An example of a data service is an identity service, such as an online corporate directory.) The Liberty ID-WSF Data Services Template Specification provides a protocol for the query and modification of the data attributes stored in a data service. The service interface specifications defined by the Liberty Alliance Project are based on this Data Services Template. For more information, see the Liberty ID-WSF Data Services Template Specification. For more information on the service interface specifications, see Liberty Identity Service Interface Specifications.

Interaction Service Specification

The Liberty ID-WSF Interaction Service Specification provides communication protocols for identity services to use when they must obtain permission from a principal (or someone who owns a resource on behalf of that principal) to allow the principal's identity data to be shared with requesting services. For more information, see the Liberty ID-WSF Interaction Service Specification.

Authentication Service Specification

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

• An authentication protocol based on the Simple Authentication and Security Layer (SASL).

• An authentication service that Liberty-enabled clients can use to authenticate with identity providers.

• A single sign-on service that Liberty-enabled providers can use to interact with each other.

The specification also defines an identity-based authentication security token service, complementing the more general security token service as discussed in the section, Discovery Service Specification. For more information, see the Liberty ID-WSF Authentication Service Specification.

Client Profiles Specification

The Liberty ID-WSF Client Profiles Specification describes the requirements for Liberty-enabled clients that interact with the SOAP-based Authentication Service. Client profiles can enable browsers to perform an active role in transactions, in addition to the functions of a standard browser. For more information, see the Liberty ID-WSF Client Profiles Specification.

Additional Liberty ID-WSF Documents

For additional information about the Liberty ID-WSF specifications, the following documents are available on the Liberty ID-WSF 1.1 specification page.

• Liberty ID-WSF Architecture Overview

  Provides an architectural description of the Liberty ID-WSF framework including basic usage scenarios. It also highlights how the Liberty ID-WSF interacts with an identity management framework (such as the Liberty ID-FF).

• Liberty ID-WSF Security and Privacy Overview

  Provides an overview of security and privacy issues in the Liberty ID-WSF.

• Liberty ID-WSF Implementation Guidelines

  Provides guidelines on how the Liberty ID-WSF specifications should be implemented.

• Liberty ID-WSF Static Conformance Requirements

  Defines the mandatory and optional features for implementations conforming to this version of the specifications.

• Liberty ID-WSF Implementation Guidelines

  Describes the Liberty ID-WSF architecture, including examples, lessons learned, and best practices.

Liberty Identity Service Interface Specifications

The Liberty Identity Service Interface Specifications (Liberty ID-SIS) are for building identity-based web services. Included in the Liberty ID-SIS 1.0 are the following:

• Liberty ID-SIS Personal Profile Service Specification

• Liberty ID-SIS Employee Profile Service Specification

• Additional Liberty ID-SIS Service Specifications

More detailed information about the service interface specifications can be found on the Liberty Alliance Project web site.

Liberty ID-SIS Personal Profile Service Specification

The Liberty ID-SIS Personal Profile Service Specification defines an identity-based web service that keeps, updates, and offers identity data regarding a user. This service queries and updates of 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 as the principal’s account number and shopping preferences is an example of a personal profile service. For more information, see the Liberty ID-SIS Personal Profile Service Specification.

Liberty ID-SIS Employee Profile Service Specification

The Liberty ID-SIS Employee Profile Service Specification defines an identity-based web service that 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. For more information, see the Liberty ID-SIS Employee Profile Service Specification.

Additional Liberty ID-SIS Service Specifications

The Liberty Alliance Project defines several other service interface specifications not discussed in this section, including a contact book, a geolocation service, and a presence service. For more information on these services, see the Liberty ID-SIS Specifications page.

Schema Files and Service Definition Documents

The Liberty Alliance Project has created a number of XML Schema Definition (XSD) files and Web Services Description Language (WSDL) documents to complement the specifications. XSD files specify the information that the corresponding service can host by defining the data and data structure. Typically, this structure is hierarchical and has one root node. Individual branches of the structure can be accessed separately, and the whole structure can be accessed by pointing to the root node. The data might be stored in implementation-specific ways. However, the data will be exposed by the service using the XML schema and the WSDL definition of the service type.

The purpose of an XML schema is to describe the structure of an XML document. The XML schema file format is XSD. XSD is an XML-based alternative to the Document Type Definition (DTD) format. A DTD also describes the structure of an XML document, but it is not in the XML format.

The WSDL definition is XML-based and describes how to communicate with the web service; namely, protocol bindings and message formats. In simpler terms, the WSDL for a specific service describes the public interface for that web service. The available XSD files and WSDL documents specific to the previously described specifications can be found on the Liberty Alliance Project web site.

Support Documents

The Liberty Alliance Project has also created a number of support documents including a metadata service protocol, reverse HTTP bindings, and a glossary. A listing of these documents and the appropriate links can be found on the Support Documents and Utility Schema Files page.

Chapter 2 Implementation of the Liberty Alliance Project Specifications

Sun Java System Access Manager contains the Sun Microsystems implementation of the Liberty Alliance Project specifications. This chapter provides an overview of how these specifications have been implemented. It covers the following topics:

• Overview

• The Federation Module

• The Liberty-based Web Services Modules

• The Liberty-based Application Programming Interfaces

• The SAML Service

• Liberty-Based Samples

Overview

Sun Java System Access Manager is a software product that helps organizations manage secure access to the resources and web applications within their intranet and across the Internet. The initial release of Access Manager implemented the Liberty Identity Federation Framework (Liberty ID-FF) specifications, focusing on identity and provider federation, authentication domains, and single sign-on. Subsequent releases of Access Manager added new features as defined in version 1.2 of the Liberty ID-FF specifications as well as the version 1.1 specifications of the Liberty Identity Web Services Framework (Liberty ID-WSF). These web services include a framework for retrieving and updating identity data.

Identity data consists of all the information that companies maintain about individual customers, corporate partners, and employees. The data is stored in identity-based service providers (also referred to as identity providers) across the Internet. Federating the sources of identity data allows for accessing, transporting, sharing, and managing the data between partnered organizations and their applications without weakening existing security safeguards. For example, many corporations provide access to outsourced human resources services, such as health benefits and 401(k) plans. The corporate intranet offers central access to these services, but employees have to log in and authenticate themselves every time they access each service. Since employees might not want to share the same profile and password with both their 401(k) provider and their health care provider, federation of their identity data can provide seamless integration of these web resources across multiple security domains within the same enterprise.

To achieve this integration, enterprises can construct a network of partnered services for securely exchanging customer account information, transaction data, and credentials through a set of interoperable web services. Federation among partner networks allows identities to share key pieces of their respective data without sharing control. For example, logging in to one web site that represents an authentication domain consisting of an airline, a car rental company, and a hotel chain allows an identity to make travel plans even if one of the sites does not contain an identity data store.

The following sections contain additional information regarding the implementation of the Liberty Alliance Project specifications in Access Manager.

• Sample Use Case

• Liberty Alliance Project Architecture in Access Manager

Sample Use Case

Using a cell phone, a principal is able to access a ring-tone vendor's site. Due to implementation of single sign-on, the ring-tone vendor recognizes the principal from the cell-phone provider's authentication. This allows the principal to purchase ring tones by interacting with the user's bank for payment. The following figure illustrates the process of requesting a service and being authenticated for access. It assumes the following:

• MyWireless is a cellular service provider and an identity provider in a federation framework that contains access to the discovery service in a web services framework.

• MyRingtones is a service provider in a federation framework that also acts as a web service consumer (WSC) in a web services framework. It sells ringtones for use with cellular phones.

• MyBank is a web service provider (WSP) in a web services framework. Linking MyBank to My Ringtones offers the opportunity for seamless purchases.

The same web service can act as a different entity in different scenarios.

Figure 2–1 Process in a Liberty-enabled Use Case

The user attempts to access MyRingtones and, after being prompted for credentials stored with MyBank, receives authorization through MyWireless. Single sign-on is accomplished in the back end. The entire process is based on implementations of the Liberty ID-FF, Liberty ID-WSF, and Liberty ID-SIS specifications.

Liberty Alliance Project Architecture in Access Manager

The figure below shows the architecture of the Access Manager features that are based on the Liberty Alliance Project specifications. These features leverage existing Access Manager services including those for policy, service management, session management, and auditing.

Figure 2–2 Liberty-based Architecture of Access Manager

For a complete architectural overview of Access Manager, see the Sun Java System Access Manager 7.1 Technical Overview.

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.

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

• Identity Federation and Single Sign-On

• Authentication and Authentication Context

• Identifiers and Name Registration

• Global Logout

• Dynamic Identity Provider Proxying

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.

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

• Bulk Federation

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.

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.

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.

The Liberty-based Web Services Modules

Liberty-based web services are those based on specifications in the Liberty ID-WSF and the Liberty ID-SIS. They are accessible from the Access Manager Console by clicking the Web Services tab. The following diagram illustrates how the different web service specifications have been implemented.

Figure 2–3 Architecture of Liberty-based Web Services

The web interface for the Liberty ID-WSF in Access Manager is accessible from the Web Services tab in the Access Manager Console, as shown. The implemented web services include:

• Liberty Personal Profile Service

• Discovery Service

• SOAP Binding Service

• Authentication Web Service

Liberty Personal Profile Service

The Liberty Personal Profile Service is 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. For more information, see Chapter 7, Data Services.

Discovery Service

The Discovery Service is 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 location of the requested attribute provider. (A resource offering defines associations between a piece of identity data and the service instance that provides access to the data.) The implementation of the Discovery Service includes Java and web-based interfaces. For more information, see Chapter 8, Discovery Service.

By definition, a discoverable service is assigned a service type Uniform Resource Identifier (URI), allowing the service to be registered in Discovery Service instances. The service type URI is typically defined in the Web Service Definition Language (WSDL) file that defines the service.

SOAP Binding Service

The SOAP Binding Service is the method of transport used to convey identity data between web services. It includes 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. The service invokes the correct request handler class (specified by a service endpoint) to handle the messages. For more information, see Chapter 9, SOAP Binding Service.

Authentication Web Service

The Authentication Web Service adds authentication functionality to the SOAP binding. It provides authentication to a WSC, allowing the WSC to obtain security tokens for further interactions with other services at the same provider. These other services may include a discovery service or single sign-on service. Upon successful authentication, the final Simple Authentication and Security Layer (SASL) response contains the resource offering for the Discovery Service. For more information, see Chapter 6, Authentication Web Service.

Do not confuse the Liberty-based Authentication Web Service with the proprietary Access Manager Authentication Service discussed in the Sun Java System Access Manager 7.1 Technical Overview.

The Liberty-based Application Programming Interfaces

A number of the Liberty-based web services specifications have also been implemented in the back end of Access Manager as APIs. The services include the Interaction Service and PAOS binding. The following table summarizes the public APIs. They can be used to deploy Liberty-enabled components or extend the core services.

For more information, see Chapter 11, Application Programming Interfaces. For detailed API documentation, including classes, methods and their syntax and parameters, see the Java API Reference in /AccessManager-base/SUNWam/docs or on docs.sun.com.

The SAML Service

Access Manager uses SAML as the means for exchanging security information. SAML uses an eXtensible Markup Language (XML) framework to achieve interoperability between vendor platforms that provide SAML assertions. Originally, the Liberty ID-FF was created as an extension of SAML 1.0 and 1.1. With the release of SAML 2.0 though, the Liberty ID-FF has been rolled into the SAML 2.0 specifications. Going forward, SAML 2.0 will be used by the Liberty Alliance Project to build additional federation—based applications. See The Liberty ID-FF Convergence for more information.

The configuration and usage of the SAML Service is independent of the SAML functionality used by the Liberty-based features in Access Manager. SAML usage by the Liberty-based features in Access Manager is behind the scenes and not configurable.

Access Manager 7.1 supports SAML 1.1 and 2.0. SAML 1.1 is supported out of the box and can be configured using the Access Manager Console. SAML 2.0 is supported after installing the SAML v2 Plug-in for Federation Services on top of a working instance of Access Manager. For more information on the SAML Service (based on SAML 1.1), see Chapter 10, SAML Administration. For more information on the SAML v2 Plug-in for Federation Services, see the Sun Java System SAML v2 Plug-in for Federation Services Release Notes and the Sun Java System SAML v2 Plug-in for Federation Services User’s Guide.

Liberty-Based Samples

Access Manager has included sample code and files that can be used to further understand the implementation of the Liberty Alliance Project specifications. For information about the specifics of these samples, see the individual chapters or Appendix A, Liberty-based and SAML Samples.