Sun Java Systems Access Manager 6 2005Q1 Federation Management Guide |
Chapter 1
Introduction to the Liberty Alliance ProjectSun Java System Access Manager implements identity federation and Web services specifications defined by the Liberty Alliance Project. Before describing how this is accomplished, this appendix explains the concept of identity, identity services, the purpose of identity federation, and the role of the Liberty Alliance Project in creating identity-based solutions. It contains the following sections:
OverviewIn 2001 Sun Microsystems joined with other major companies to form the Liberty Alliance Project (LAP). The goal of the LAP is to define standards for developing identity-based infrastructures, software, and Web services, and to promote adoption of these standards. The LAP does not deliver products or services; it defines frameworks to ensure interoperability between homogeneous products while respecting the privacy and security of identity data.
Note
If you are already familiar with the concepts and protocols developed by the Liberty Alliance Project, feel free to move on to Chapter 2, "Implementation of the Liberty Specifications" which begins to describe how these standards are integrated into the Sun Java System Access Manager product.
LAP Members
The members of the LAP include some of the world’s most recognized brand names, representing products, services and partnerships across a wide spectrum of consumer and business service providers. The consortium also includes government organizations and technology vendors. A complete listing of current members of the LAP can be found at http://www.projectliberty.org/membership/current_members.php.
Note
Only members of the Liberty Alliance Project are allowed to provide feedback on drafts of the specifications although any organization may implement them.
LAP Objectives
The specifications developed by the LAP enable individuals and organizations to securely conduct network transactions. More specifically, they:
- Serve as open standards for federated identity management and Web services.
- Support and promote permission-based sharing of personal identity attributes.
- Provide a single sign-on standard that includes decentralized authentication and authorization for multiple providers.
- Create an open network identity infrastructure that supports all current and emerging user agents (network access devices such as Web browsers, or wireless browsers).
- Enable consumers to protect their network identity information.
The Concept of IdentityIdentity can be defined as a set of information by which one person is definitively distinguished. In the real world, this information starts with a document that defines your name: a birth certificate. Over time, additional information further designates aspects of your identity:
Each of these distinct documents represents data that defines your identity specifically to the enterprise for which it was issued. The composite of this data constitutes an overall identity with each specific piece detailing a distinguishing characteristic.
Because the Internet is becoming the primary vehicle for the interactions represented by this identity-defining information, people are now creating identities online for the enterprises with which they interact. By defining a user identifier and password, an email address, your personal preferences (style of music, access device, opt-in/opt-out marketing decision, email frequency), and other information more specific to the particular business (social security number, credit records, bank account number, bill payment information, ship-to address), users distinguish themselves from others who use the enterprise’s services by creating this virtual identity. The virtual identity is referred to as a local identity because it is specific to the service provider for which it has been set. Considering the number of service providers for which you can define a local identity, it can make accessing each one time-consuming and frustrating. In addition, although most local identities are configured independently (and fragmented across the Internet), it might be useful to connect the information; for example, your local identity with a bank could be securely connected to your local identity with a retailer. Identity federation is the solution to this issue.
The Concept of Identity FederationConsider the many times you might access service provider accounts in a single day; sending and receiving email, logging in to a news portal, checking bank balances, finalizing travel arrangements, bidding on auction items, accessing utility accounts, and shopping online are all possible services for which you would define an identity. Each time you want to access one of these services, you identify yourself to the provider by logging in. If you use all of these services, you’ve configured a multitude of separate accounts that you must log in to (and log out of) for access. This virtual identity phenomenom offers the opportunity to fashion a system for computer users to link their local identities. Identity federation allows the user to associate, connect or bind the various local identities they have configured for multiple service providers. The linked local identities, referred to as a federated identity, then allow the user to log in to one service provider site and click through to an affiliated service provider site without having to re-authenticate or re-establish their identity. This notion of single sign-on is an option to which the user must agree. The Liberty Alliance Project was implemented to define standards using open technologies, therefore encouraging an interoperational infrastructure among service providers, and identity federation among users.
Liberty Alliance Project ConceptsA number of concepts are derived from the LAP specifications (discussed in The Liberty Alliance Project Specifications). Definitions for them are provided here.
Account Federation (Identity Federation)
Account federation occurs when a user chooses to unite distinct service provider accounts with one or more identity provider accounts. Users retain the individual account information with each provider while, simultaneously, establishing a link that allows the exchange of authentication information between them.
Affiliation
An affiliation is a group of providers formed without regard to their particular authentication domain. It is formed and maintained by an affiliation owner. An affiliation document describes a group of providers collectively identified by their providerID. Members of an affiliation may invoke services either as a member of the affiliation (by virtue of their Affiliation ID) or individually (by virtue of their Provider ID).
Attribute Provider
An attribute provider is a web service that hosts attribute data. An example of an attribute provider would be an instance of the Personal Profile Service defined in Liberty Identity Service Interface Specifications.
Authentication Domain
A authentication domain is a group of service providers (with at least one identity provider) who agree to join together to exchange user authentication information using Liberty-enabled technologies. Once an authentication domain is established, single sign-on can be enabled amongst all membered providers. An authentication domain is sometimes referred to as a Circle Of Trust.
Circle Of Trust
Client
A client is actually the role any system entity assumes when making a request of another system entity. (In this scenario, the system entity of which the request is made is termed a Server.)
Common Domain
In an authentication domain having more than one identity provider, service providers need a way to determine which identity provider a principal uses. Because this function must work across any number of domain name system (DNS) domains, the Liberty approach is to create one domain common to all identity and service providers in the authentication domain. This predetermined domain is known as the common domain. Within the common domain, when a principal has been authenticated to a service provider, the identity provider writes a common domain cookie that stores the principal’s identity provider. Now, when the principal attempts to access another service provider within the authetnication domain, the service provider reads the common domain cookie and the request can be forwarded to the correct identity provider.
Defederation
Federation Cookie
A federation cookie is a cookie implemented by Access Manager with the name fedCookie. It can have a value of either yes or no based on the principal’s federation status. The concept was developed for Access Manager, and is not a defined part of the LAP specifications. Information on how a federation cookie is used can be found in The Process of Federation of Chapter 3, "Federation Management."
Federated Identity
A federated identity refers to the amalgamation of the account information in all service providers accessed by one user (personal data, authentication information, buying habits and history, shopping preferences, etc.). The information is administered by the user yet, with the user’s consent, privilege to access the information is securely shared with their providers of choice.
Federation Termination
Users have the ability to terminate their federations. Federation termination (or defederation) results in the cancellation of affiliations established between the user’s identity provider and their federated service provider accounts.
Identity Provider
An identity provider is a service provider that specializes in providing authentication services. As the administrating service for authentication, identity providers also maintain and manage identity information. Authentication accomplished by an identity provider is honored by all service providers with whom it is affiliated. This term is used when defining an entity of this sort enabled by the ID-FF.
Identity Service
An identity service is a Web service that acts upon a resource to retrieve, update, or perform some action on data attributes related to a principal (an identity). An example of an identity service might be a corporate phone book or calendar service.
Liberty-enabled Client
A Liberty-enabled client is a client that has, or knows how to obtain, informatiuon about the identity provider that a principal will use to authenticate to a service provider.
Liberty-enabled Proxy
A Liberty-enabled proxy is an HTTP proxy that emulates a Liberty-enabled Client.
Name Identifier
To help preserve anonymity when identity information is exchanged between identity and service providers, an arbitrary name identifier is used. This pseudonym allows the providers to identify a principal without knowledge of the user’s actual identity. The name identifier has meaning only in the context of the relationship between partners.
Principal
A principal is an entity that can acquire a federated identity, that is capable of making decisions, and to which authenticated actions are done on its behalf. Examples of principals include an individual user, a group of individuals, a corporation, other legal entities, or a component of the Liberty architecture.
Pseudonym
See Name Identifier.
Receiver
A receiver is the role taken by a system entity when it receives a message sent by another system entity. (In this scenario, the system entity from which the message is received is termed a Sender.)
Resource Offering
In a discovery service, a resource offering defines associations between a piece of identity data and the service instance that provides access to it.
Sender
A sender is the role donned by a system entity when it constructs and sends a message to another system entity. (In this scenario, the system entity from which the message is received is termed a Receiver.)
Server
A server is actually the role any system entity assumes when providing a service in response to a request from another system entity. (In this scenario, the system entity from which the request is received is termed a Client.)
Service Provider
A service provider is a commercial or not-for-profit organization that offers web-based services to a principal. This broad category can include internet portals, retailers, transportation providers, financial institutions, entertainment companies, libraries, universities, and governmental agencies. This term is used when defining an entity of this sort enabled by the ID-FF.
Single Logout
A single logout occurs when a user logs out from an identity provider or a service provider. By logging out from one provider, they will effectively be logged out from all service providers or identity providers in that authentication domain.
Single Sign-on
Single sign-on is established when a user with a federated identity authenticates to an identity provider. Because they have previously opted-in for federation, they are now able to access affiliated service providers without having to re-authenticate.
Trusted Provider
A trusted provider is a generic term for one of a group of service and identity providers in an authentication domain. Users can transact and communicate with trusted providers in a secure environment.
Web Service Consumer
A Web service consumer invokes the operations a Web service provides by making a request to a Web service provider. This term is used when defining an entity of this sort enabled by the ID-WSF.
Web Service Provider
A Web service provider implements a Web service based on a request from a Web service consumer. It may run on the same Java virtual machine as the Web service consumer using it. This term is used when defining an entity of this sort enabled by the ID-WSF.
The Liberty Alliance Project SpecificationsThe LAP develops and delivers specifications that enable federated network identity management. Using Web redirection and open-source technologies like SOAP and XML, the LAP specifications enable distributed, cross-domain interactions. The LAP specifications are divided into three components:
Liberty Identity Federation Framework
The Liberty Identity Federation Framework (ID-FF) defines a set of protocols, bindings and profiles that provides a solution for identity federation, cross-domain authentication and session management. These definitions can be used to create a brand new identity management system or develop one in conjunction with legacy systems. The ID-FF is designed to work with heterogeneous platforms, all types of networking devices (including personal computers, mobile phones, and PDAs), and other emerging technologies. A scenario implementing these specifications includes the subjects illustrated in Figure 0-1 and defined beneath it.
Figure 0-1 Concepts of the ID-FF Specifications
- A principal has a defined local identity with one or more providers, and has the option to federate these identities. The principal might be an individual user, a grouping 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 be it a news portal, a financial repository, or retail outlet. This broad category can also include:
- An identity provider is a service provider that stores identity profiles and offers incentives to other service providers for the prerogative to federate their user identities. (Identity providers might also offer services above and beyond those related to identity profile storage.)
- In order to support identity federation, both service and identity providers must join together into an authentication domain (also referred to as a circle of trust). In an authentication domain, providers representing products, services and partnerships across a wide spectrum of consumer and business enterprises agree to join together to exchange authentication information using the LAP specifications. An authentication domain must contain at least one identity provider (to maintain and manage identity profiles) as well as at least two service providers. (One organization may be both an identity provider and a service provider.)
The set of ID-FF protocols include:
Note
More detailed information on the Liberty Identity Federation Framework can be found in the Liberty ID-FF Protocols and Schema Specifications (http://www.projectliberty.org/specs/draft-liberty-idff-protocols-schema-1.2-errata-v1.0.pdf).
Single Sign-on and Federation Protocol
The Single Sign-on and Federation Protocol defines a request/response protocol by which a principal is able to authenticate to a service provider, and federate (or link) their identities. A service provider issues a request for authentication to an identity provider. The identity provider responds with a message containing authentication information, or an artifact that points to authentication information which can then be de-referenced into authentication information. Additionally, the identity provider can federate the principal’s identity (configured at the identity provider level) with the principal’s identity (configured at the service provider level).
Note
Under certain conditions, an identity provider may issue an authentication response to a service provider without having received an authentication request.
The Single Sign-on and Federation Protocol also defines controls that allow for the following behaviors:
Account federation. Principals can choose to federate their identity at the identity provider with their identity at the service provider.
Authentication context. Service providers can choose the type and level of authentication that should be used when the principal logs in.
Authentication credentials. Principals may be prompted for credentials at the behest of the service provider.
Account handle. An identity provider can issue an anonymous and temporary identifier to refer to a particular principal during communication with a service provider. This identifier is used to obtain information for or about principals (with their permission) during federation.
Caution
This account handle is generated by the identity provider during federation unlike the handle that can be generated by the service provider after federation using the Name Registration Protocol.
Dynamic proxying. An identity provider that is asked to authenticate a principal it believes has already authenticated via another identity provider may make an authentication request on behalf of the requesting provider to the authenticating identity provider.
Identity provider introduction. When an authentication domain has more than one identity provider, a service provider can use this feature to discover which identity provider a principal is using.
Message exchange profiles. The authentication request defines how messages are exchanged between identity providers and service providers. The particular transfer and messaging protocol (HTTP, SOAP, etc.) used in the exchange are specified in profiles. Two of them are:
Name Registration Protocol
The Name Registration Protocol is an optional-use protocol used by the service provider to create its own opaque handle to identify a principal when communicating with the identity provider.
Caution
This handle is not related to the opaque handle generated by the identity provider during federation as defined in the Single Sign-on and Federation Protocol. The Name Registration Protocol can, though, be used by the identity provider to change the opaque handle they registered with the service provider during initial federation.
Federation Termination Protocol
The Federation Termination Protocol defines how one provider (of either type) notifies another provider (of either type) when a principal has terminated their identity federation. The notification is in the form of a one-way, asynchronous message which states that either the service provider will no longer accept authentication information regarding the particular user, or the identity provider will no longer provide authentication information regarding the particular user.
Single Log-out Protocol
The Single Log-out Protocol defines how providers will notify each other of logout events. This message exchange protocol is used to terminate all sessions when a log out occurs at the service provider or identity provider level. The particular transfer and messaging protocol (HTTP, SOAP, etc.) used in the exchange are specified in profiles. Two of them are:
Name Identifier Mapping Protocol
The Name Identifier Mapping Protocol defines how service providers can obtain name identifiers for a principal that has federated in the name space of a different service provider. This can be accomplished by querying an identity provider that has federated the user with both service providers. This allows the requesting provider to communicate with the other service provider without an identity federation for the principal between them.
Additional ID-FF Documents
Additional information explaining the ID-FF specifications can be found in the documents detailed in Table 0-1.
Table 0-1 Additional Help with the ID-FF
Name of Document
Overview
Liberty ID-FF 1.2 Architecture Overview
http://www.projectliberty.org/specs/liberty-idff-arch-overview-v1.2.pdf
The Architecture Overview provides an architectural description of the ID--FF framework as well as policy, security and technical notes.
Liberty ID-FF 1.2 Protocols and Schema Specification
http://www.projectliberty.org/specs/draft-liberty-idff-protocols-schema-1.2-errata-v1.0.pdf
The Protocols and Schema Specification provide the abstract Liberty protocols for Identity Federation, Single Sign-on, Name Registration, Federation Termination, and Single Log-out.
Liberty ID-FF 1.2 Implementation Guidelines
http://www.projectliberty.org/specs/liberty-idff-guidelines-v1.2.pdf
The Implementation Guidelines provide guidance and checklists for implementing a Liberty-enabled environment using the ID-FF Specifications.
Liberty ID-FF 1.2 Static Conformance Requirements
http://www.projectliberty.org/specs/liberty-idff-1.2-scr-v1.0.pdf
The Static Conformance Requirements define what features are mandatory and optional for implementations conforming to this version of the ID-FF Specifications.
Liberty Identity Web Services Framework
The ID-FF defines how to implement single sign-on and identity federation to solve problems related to network identity. The Liberty Identity Web Services Framework (ID-WSF) builds upon this by providing specifications to build Web services that retrieve, update, or perform an action on, identity data in a federated network environment. The specifications outline the technical components necessary to build Web services that interoperate with identity data, such as a calendar service, a wallet service, or an alert service. A scenario implementing these specifications includes the subjects defined below.
Web services are the basis of distributed computing across the Internet. A WSC locates a Web service and invokes the operations it provides. The WSP is the application implementing a Web service; it can be on the same Java virtual machine as the WSC, or it can be thousands of miles away. When a WSC needs to retrieve identity attributes from a WSP, it must first contact a discovery service to locate where the particular attributes are stored. When this information is returned, the WSC then contacts the WSP (for example, a personal profile service) to retrieve the necessary attributes.
Note
More information on the WSC/WSP process of the Liberty ID-WSF can be found in Discovery Service Process of Chapter 6, "Discovery Service."
The defined features of the ID-WSF include:
SOAP Binding Specification
The SOAP Binding Specification details a transport layer for handling SOAP messages. Among other features, it defines SOAP header blocks and processing rules enabling the invocation of identity services via SOAP requests and responses. It also specifies how to configure messages for optimum message correlation (assuring the relationship between a SOAP request and its response), consent claims (permission to perform a certain action), and usage directives (data handling policies).
Discovery Service Specification
The Discovery Service Specification defines a framework that enables a client to locate the appropriate Web service for retrieving, updating, or modifying a particular piece of identity data. Typically, there are one or more services on a network that allow entities to perform an action on identity data. To keep track of these services or to know which can be trusted, clients require a discovery service, essentially a Web service interface for a registry of resource offerings. A resource offering defines an association between a piece of identity data and the service instance that provides access to it. A common use case is when a personal profile, or calendar data are placed within a discovery resource so that the data can be located by other entities.
Security Mechanisms Specification
The Security Mechanisms Specification describes the requirements for securing authorization decisions sent for the discovery, and use, of identity services. The specified mechanisms provide for authentication, signing and encryption operations to ensure integrity and confidentiality of the messages.
Data Services Template Specification
The Data Services Template Specification defines how to query and modify identity data attributes stored in a data service (a Web service that holds data). The specification also provides some common attributes for data services.Interaction Service Specification
The Interaction Service Specification details communication protocols for identity services to obtain permission from a principal (or someone who owns a resource on behalf of that principal) that allows the service to share their identity data with requesting services.Authentication Service Specification
The Authentication Service Specification defines how to authenticate parties communicating via SOAP-based messages. It leverages widely used authentication services and mechanisms, and facilitates selection of these services and mechanisms at deployment time. The specification defines:
The specification also defines an identity-based authentication security token service, complementing the more general security token service defined by the Discovery Service Specification.
Client Profiles for Liberty-enabled User Agents or Devices
The Client Profiles for Liberty-enabled User Agents or Devices describes the requirements for Liberty-enabled clients interacting with the SOAP-based Authentication Service. These profiles can enable browsers to perform an active role in transactions, in addition to the functions of a standard browser.
Additional ID-WSF Documents
Additional information explaining the ID-WSF specifications can be found in the documents detailed in Table 0-2.
Table 0-2 Additional Help with the ID-WSF
Name of Document
Overview
Liberty ID-WSF Web Services Framework Overview
http://www.projectliberty.org/specs/liberty-idwsf-overview-v1.0.pdf
The Web Services Framework Overview provides an architectural description of the ID-WSF framework including basic usage scenarios. It also highlights how the ID-WSF interacts with an identity management framework (such as the ID-FF).
Liberty ID-WSF Security and Privacy Overview
http://www.projectliberty.org/specs/liberty-idwsf-security-privacy-overview-v1.0.pdf
The Security and Privacy Overview provides an overview of security and privacy issues in ID-WSF.
Liberty Identity Service Interface Specifications
The Liberty Identity Service Interface Specifications (ID-SIS) contain the following specifications for building these identity-based Web services:
Personal Profile Service
The Personal Profile Service defines an identity-based Web service that keeps, updates, and offers identity data regarding a user. The Personal Profile Service is characterized by the ability to query and update attribute data and incorporates mechanisms for access control and conveying data validation information and usage directives from other specifications. A shopping portal that offers information such the principal’s account number and shopping preferences is an example of a personal profile service.Employee Profile Service
The Employee Profile Service defines an identity-based web service which keeps, updates, and offers profile information regarding a user’s workplace. An online corporate phone book that provides an employee name, office building location, and telephone extension number is an example of an employee profile service.
Supporting Documents
There are many other support documents in the LAP specifications. They include a metadata service protocol, reverse HTTP bindings, a glossary, and schema files. More information can be found at the LAP Web site or, more specifically, at http://www.projectliberty.org/resources/specifications.php#box4.
Deploying a Liberty-based SystemThis section details a few things to consider when building a successful Liberty-based implementation.
Size Up Your IT Staff
Although the LAP specifications are aimed at large organizations, small and medium-sized companies with a saavy IT staff can also roll out a federated identity system. The specifications are complicated and cross several domains of expertise (Web services development, XML, networking, and security).
Clean Your Directory Data
The LAP specifications do not specify where you store identity data; they are more concerned with it’s accuracy. Purge your data store of old identity profiles, consolidate multiple (or delete duplicated) identity profiles, and ensure privileges are assigned correctly.
Caution
Identity Providers should enforce strong passwords. A stolen identity can be abused across multiple sites in a federated system.
Draft Business Agreements
The LAP specifications assume pre-existing trust relationships between members in a Circle of Trust. This trust is defined through business arrangements or contracts that describe the technical, operational, and legal responsibilities of each party and the consequences for failing in them. When defined, a Liberty trust relationship means that one organization trusts another’s user authentication decisions. That trust among members lets a user log in at one site and access another site as well: single sign-on (SSO). Ensure that these agreements are in play before going live with a Liberty-compliant system.
Liberty-compliant Technology
At the minimum, a Liberty-compliant identity server is needed to process Liberty-based requests and responses. Chapter 2, "Implementation of the Liberty Specifications" begins our discussion of Sun Microsystems’ implementation of the LAP specifications, the Sun Java System Access Manager.