Sun Java System Access Manager 7.1 Federation and SAML Administration Guide

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

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.

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

An image illustrating the Liberty Identity Federation
Framework model.

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

Illustration of 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:

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.

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

Caution –

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.

Note –

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.

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:

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.

Note –

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.