Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide

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.

This chapter covers the following topics:

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.

Note –

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 a complete listing of current members, see the Liberty Alliance Project web site.

Note –

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 identity 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 provider 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

Federation, as it has evolved with regard to the World Wide Web, begins with the notion 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. Now, in order to access the service, the user logs in to the service provider, a networked entity that provides services to other entities.

If a user accesses these services, many user accounts have been configured separately. This virtual phenomenon offers an opportunity to fashion a system for users to federate their disparate service provider identities.

Identity federation allows the user to link, connect, or bind the local identities that have been created for the multiple service providers. 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 must also include at least one identity provider. An identity provider is a service provider that maintains and manages identity data, and provides authentication services.

Note –

The establishment of contractual agreements between providers is beyond the scope of this guide. For information, see the Liberty Trust Model Guidelines.

After the contracts and policies defining a circle of trust are in place, the specific protocols, profiles and security mechanisms being used in the deployment are distilled into a metadata document that is exchanged between the members of the circle of trust. Access Manager provides the tools necessary to integrate the metadata and enable the circle 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.

Liberty Alliance Project Concepts

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

Account Federation

See Identity Federation.

Affiliation

An affiliation is a group of providers formed without regard to a particular authentication domain. 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 Chapter 3, Federation for more information.

Attribute Provider

An attribute provider is a web service that hosts attribute data, for example, an instance of the Liberty Personal Profile Service data service. For more information, see Chapter 6, 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 (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 SAML assertion consumer. The following XML example describes a user having authenticated with a password over an SSL-protected session:

Example 1–1 XML 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>

Authentication Domain

An authentication domain is a federation of service providers (with at least one identity provider) that is configured technologically. The providers interact using the Liberty Alliance Project specifications. The term authentication domain does not encompass the prerequisite business agreements established between providers in a circle of trust. After the circle of trust is established, an authentication domain can be configured and single sign-on can be enabled.

Note –

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

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

Note –

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 the consolidated account information that a user has provided to service providers. Personal data, authentication information, buying habits and history, and shopping preferences are examples of user account information. The information is administered by the user, and can be securely shared with other service providers.

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) 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 6, 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 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 Liberty-based profile defines the combination of a message's content and its transport mechanisms for a user agent.

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

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 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 without having to re-authenticate is available.

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.

Note –

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:

There are also many support documents in the specifications, including a metadata service protocol, reverse HTTP bindings, a glossary, and schema files. For more information on all of the documents, see the Liberty Alliance Project web site.

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. 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 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, both service and identity providers must join together into an authentication domain. An authentication domain 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.

Organizations in an authentication domain must first write operational agreements to define their relationships in a circle of trust. An operational agreement is a contract between organizations that defines how the circle will work. For more information, see Authentication Domain and Provider Federation.

Liberty ID-FF Protocols and Schema

The Liberty ID-FF Protocols and Schema Specifications defines these abstract protocols:

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 a request and response protocol by which a principal is able to authenticate to one or more service providers and federate (or link) configured identities. A service provider issues a request for authentication to an identity provider. The identity provider responds with a message that contains authentication information, or an artifact that points to authentication information. The identity provider can also 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. 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. 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 profiles. 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. 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.
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 is used by the service provider to create its own opaque handle to identify a principal when communicating with the identity provider.

Note –

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 how the identity provider or the service provider notifies the other provider when a principal has terminated identity federation. The notification is a one-way, asynchronous message which 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 how providers notify each other of logout events. This message exchange protocol is used to terminate all sessions when a logout occurs at the service provider or identity provider. The particular transfer and messaging protocol used in the exchange (such as HTTP or SOAP) are specified in profiles. Two of these profiles are:

The SOAP/HTTP-based profile relies on asynchronous SOAP over HTTP messaging calls between providers.
The HTTP Redirect-based profile relies on HTTP redirects between providers.

Name Identifier Mapping Protocol

The Name Identifier Mapping Protocol defines how service providers can obtain name identifiers that are assigned to a principal that has federated in the name space of a different service provider. When a principal authenticated to one service provider requests access to a second service provider site, the second service provider can use this protocol to obtain the name identifier. 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 them.

Liberty ID-FF Bindings and Profiles

The Liberty ID-FF Bindings and Profiles Specification defines the bindings and profiles for the Liberty protocols and messages sent to HTTP-based communication frameworks. This specification relies on the core SAML framework. For example, the Name Identifier Encryption Profile permits a principal’s name identifier to be encrypted so that only the provider possessing the decryption key can realize the identity. The encrypted identifier is a different value when requested by different providers. Using different values reduces the chance for correlation of the encrypted value across multiple logical transactions. For more information about the Name Identifier Encryption Profile and the specification 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, see the following documents.

Liberty ID-FF 1.2 Architecture Overview

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

Provides guidance and checklists for implementing a Liberty-enabled environment using the Liberty ID-FF specifications.
Liberty ID-FF 1.2 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 to develop web services that retrieve, update, or perform an action on identity data in a federated network environment. The specifications outline the technical components needed to build web services that operate with identity data, such as a calendar service, a wallet service, or an alert service. A scenario that implements these specifications includes the following subjects:

A web service consumer (WSC) invokes the operations that a web service provides by making a request to a web service provider.
A web service provider (WSP) implements a web service based on a request from a web service consumer.

Web services are the basis of distributed computing across the Internet. A WSC locates a web service and invokes the operations the web service provides. The WSP is the application that implements a web service. The web service 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, the WSC 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.

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

Liberty ID-WSF Specifications

The Liberty ID-WSF includes these specifications:

SOAP Binding Specification

The Liberty ID-WSF SOAP Binding Specification provides a transport layer for handling SOAP messages. It defines SOAP header blocks and processing rules that enable the invocation of identity services using SOAP requests and responses. It also specifies how to 1) configure messages for optimum message correlation, assuring the relationship between a SOAP request and its response, 2) consent claims (permission to perform a certain action), and 3) usage directives (data handling policies). 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 a discovery service. A discovery service is 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 the data. A common use case is when a personal profile or calendar data is placed within a discovery resource so that the data can be located by other entities. For more information, see the Liberty ID-WSF Discovery Service Specification.

Security Mechanisms Specification

The Liberty ID-WSF Security Mechanisms Specification describes the requirements for securing authorization decisions that are 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. For more information, see the Liberty ID-WSF Security Mechanisms Specification.

Data Services Template Specification

The Liberty ID-WSF Data Services Template Specification defines how to query and modify the identity data attributes that are stored in a data service (a web service that holds data). The specification also provides common attributes for data services. For more information, see the Liberty ID-WSF Data Services Template Specification.

Interaction Service Specification

The Liberty ID-WSF Interaction Service Specification provides 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 the principal's identity data 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-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 following:

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, see the following documents:

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 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 are the following:

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 Liberty ID-SIS that are not discussed in this section, including a contact book, a geolocation service, and a presence service. For more information on these services, see the documentation in the Liberty ID-SIS.

Deploying a Liberty-based System

To build a successful Liberty-based implementation, consider the issues described in this section. At the minimum, a Liberty-compliant identity server is needed to process Liberty-based requests and responses.

Assess the Qualifications of Your IT Staff

Although the specifications are aimed at large organizations, small and medium-sized companies with an experienced IT staff can also roll out a federated identity system. The specifications are complex and require several areas of expertise, including web services development, XML, networking, and security.

Clean Up Directory Data

The specifications do not specify where to store identity data. Purge your data store of old identity profiles, consolidate multiple (or delete duplicated) identity profiles, and ensure that privileges are assigned correctly.

Tip –

Identity providers must enforce strict regulations regarding passwords. A stolen identity can be abused across multiple sites in a federated system.

Draft Business Agreements

The specifications assume 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 not completing them. When defined, a Liberty trust relationship means that one organization trusts another’s user authentication decisions. That trust among members enables a user to log in at one site and access another site as well. Ensure that these agreements are in force before going live with a Liberty-compliant system including configured authentication domains.