Federation establishes a standards-based method for sharing and managing identity data and establishing single sign-on across security domains and organizations. It allows an organization to offer a variety of external services to trusted business partners as well as corporate services to internal departments and divisions. Forming trust relationships across security domains allows an organization to integrate applications offered by different departments or divisions within the enterprise as well as engage in relationships with cooperating business partners that offer complementary services. Towards this end, multiple industry standards, such as those developed by the Organization for the Advancement of Structured Information Standards (OASIS) and the Liberty Alliance Project, are supported. This chapter contains an overview of federation.
As a concept, federation encompasses both identity federation and provider federation.
In one dictionary, identity is defined as ”a set of information by which one person is definitively distinguished.” This information undoubtedly begins with the document that corroborates a person's name: a birth certificate. Over time, additional information further defines different aspects of an individual's identity. The composite of this data constitutes an identity with each specific piece providing a distinguishing characteristic. Each of the following represents data that designates a piece of a person's identity as it relates to the enterprise for which the data was defined.
A telephone number
One or more diplomas
A driver’s license
Financial institution accounts
Because the Internet is now one of the primary vehicles for the types of interactions represented by identity-defining information, people are creating online identities specific to the businesses with which they are interacting. By creating a user account with an identifier and password, an email address, personal preferences (such as style of music, or opt-in/opt-out marketing decisions) and other information specific to the particular business (a bank account number or ship-to address), a user is able to distinguish their account from others who also use the enterprise’s services. This distinguishing information is referred to as a local identity because it is specific to the service provider (a networked entity that provides one or more services to other entities) for which it has been defined. 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 a local identity. If a user accesses all of these services, many different local identities have been configured. Considering the number of service providers for which a user 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 utility company for easy, online payments. This virtual phenomenon offers an opportunity for a system in which users can federate these local identities. Identity federation allows the user to link, connect, or bind the local identities that have been created for each service provider. 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; in effect, single sign-on (SSO).
Provider federation begins with a circle of trust. A circle of trust is a group of service providers who contractually agree to exchange authentication information. Each circle of trust must include at least one identity provider, a service provider that maintains and manages identity data, and provides authentication services. After the business contracts and policies defining a circle of trust are in place, the specific protocols, profiles, endpoints, and security mechanisms being used by each member is collected into a metadata document that is exchanged among all other members of the circle. OpenSSO Enterprise provides the tools necessary to integrate the metadata and enable a circle of trust technologically. Authentication within this federation is honored by all membered providers.
The establishment of contractual trust agreements between providers is beyond the scope of this guide. See The Concept of Trust for an overview.
Federating identities assumes existing trust relationships between participants. 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 trust agreements are in force before configuring circles of trust with OpenSSO Enterprise and going live. The Liberty Alliance Project has created a support document for helping to establish these trust arrangements. The Liberty Trust Model Guidelines document is located on the Support Documents and Utility Schema Files page of the Liberty Alliance Project web site.
The goal of federation is to enable individuals and service providers to protect identity data while conducting network transactions across secure domains. When organizations form a trust agreement, they agree to exchange user authentication information using specific web technologies. The trust agreement would be among multiple service providers that offer web-based services to users and, at least, one identity provider (a service provider that maintains and manages identity information). Once metadata (a particular provider's federation configuration information) is exchanged and the trust is established technologically, single sign-on can be enabled between all the included providers, and users may opt to federate their multiple identities (depending on the protocol being used). In OpenSSO Enterprise, the trust agreement is virtually configured as a circle of trust using the console or command line interface. A circle of trust contains providers (service providers or identity providers) that are grouped together for the purpose of offering identity federation. Identity federation occurs when a user chooses to unite distinct service provider and identity provider accounts while retaining the individual account information with each provider. The user establishes a link that allows the exchange of authentication information between provider accounts. Users can choose to federate any or all identities they might have. After identity federation, when a user successfully authenticates to one of the service providers, access to any of the federated accounts within the circle of trust is allowed without having to reauthenticate. The following figure shows the subjects involved in federation.
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 one service provider. (One organization may be both an identity provider and a service provider.) Providers in a circle of trust must first write trust agreements to define their relationships. A trust agreement is a contract between organizations that defines how the circle will work. For more information, see The Concept of Trust.
A travel portal is a good example of a circle of trust. Typically, a travel portal is a web site designed to help you access various travel-related services from one location. The travel portal forms a partnership with each service provider displayed on its web site. (This might include hotels, airlines, and car rental agencies.) The user registers with the travel portal which, in effect, is the identity provider for the circle of trust. After logging in, the user might click through to an airline service provider to look for a flight. After booking a flight, the user might click through to an accommodations service provider to look for a hotel. Because of the trust agreements previously established, the travel portal shares authentication information with the airline service provider, and the airline service provider with the accommodations service provider. The user moves from the hotel reservations web site to the airline reservations web site without having to reauthenticate. All of this is transparent to the user who must, depending on the underlying federation protocol, choose to federate any or all local identities. The following figure illustrates the travel portal example.