Federated Network Identity

Users accessing Internet-based services often use such services in ways that cater to their personal tastes and preferences. Each user account associates the user with his/her information that may include anything from personal preferences on web pages to more sensitive data such as credit card and bank account numbers. The network identity of the user is the complete set of all such information constituting the user's different accounts. However, in today's world, user accounts are scattered all over the Internet and the concept of a portable and flexible network identity is rare.

Project Liberty (http://www.projectliberty.org), a broad alliance of a wide spectrum of industries, attempts to address this issue through a series of technical specifications that can be used to realize a wide range of network-identity operations. Project Liberty implementations may ultimately provide a convenient and secure framework in which organizations may leverage new or existing relationships with customers and partners allowing for new business opportunities and increased customer satisfaction. Project Liberty provides a standards-based approach to network identity management. Several products supporting Liberty Alliance 1.1 specifications are now available—a complete list can be obtained at http://www.projectliberty.org. The solution providers include RSA Security, Entrust, Sun Microsystems, Oblix, Novell, and many others. This section primarily discusses key concepts of Project Liberty's Federated Network Identity architecture.

In a federated identity system, it is crucial that the following key objectives are realized:

• The privacy and security of personal information.

• Participating entities must be able to manage trusted relationships using a standards-based approach rather than a one-off solution.

• The realization of single sign-on standards that allow decentralized authentication and authorization of users, that is, each service provider must be able to authenticate and authorize users without having to forward user credentials to other non-essential third parties.

These objectives are realized by establishing circles of trust, an agreement common to all participants. It is based on such circles of trust that operational agreements and trust relationships are formed between service providers and users. Users can choose to federate (share) their local identities, and include them into circles of trust. A circle of trust thus becomes a federation of trusted participants that provide a seamless environment in which to conduct secure transactions. Figure 3-5 illustrates circles of trust within a federated network identity framework.

Figure 3-5: Circles of trust

Liberty Architecture

This section provides a high-level overview of the Liberty architecture, its components, and its processes.

Definitions

The provider definitions are as follows:

• Service provider Organizations providing Internet-based services. These may include virtually anything with a web presence, including businesses, portals, banks, media portals, government, and so on.

• Identity provider A type of service provider that offers identity-related services that are the basis for forming trust circles between affiliated service providers. An example of an identity provider may be a trusted system that manages employee identities across an organization and its subsidiaries.

The Liberty-enabled implementations must support the following functional requirements:

• Identity federation Protocols and stipulations that ensure users, service providers, and identity providers within a circle of trust are notified when identities are federated and de-federated (that is, added and removed from circles of trust). These protocols also mandate that all service and identity providers provide each of its users a list of the user's federated identities at that provider.

• Authentication The authentication processes in a networked identity federation requires that the following minimal scenarios be supported:

  • Navigating between identity and service providers (to exchange user-related information.

  • Preserving confidentiality, authenticity, and integrity of any information exchanged between user agents and identity providers, or between identity and service providers.

  • Presentating verifiable form(s) of identity by the Identity provider to the user before the user provides credentials or personal information to that provider.

  • Enabling service providers to request the identity provider to re-authenticate a user using the same or a different authentication class.

• Support for pseudonyms The ability to support pseudonyms (that is, aliases, assumed names, and so on) that are unique to each identity federation, across all identity and service providers.

• Global logout Support for "logout" notifications (on user logout) to related identity and service providers with whom the user has established a federated identity.

Figure 3-6 illustrates the overall Liberty architecture. The Liberty architecture is based on three orthogonal components:

• Web redirection Enables Liberty entities such as service provider, identity providers, and user agents to interact over today's installed http-based environments. On attempting to access a service hosted at a service provider, the user is first redirected to the identity provider for sign-on, subsequent to which the user is redirected back to the service provider.

• Web services Liberty protocols detail various interactions that occur between two or more Liberty-enabled providers. Each set of interactions is based on RPC-like call semantics conveyed via Simple Object Access Protocol (refer to Chapter 8 for details on RPC-oriented SOAP messages). SOAP is a well-recognized specification for conducting RPC-like interactions using XML over HTTP and is thus useful for realizing Liberty-specific protocols and orchestrations.

• Schemas and metadata A set of data formats employed by Liberty entities to exchange provider-specific information and other identity artifacts among each other. Please refer to section 5.3 of the Liberty Architecture Overview [Version 1.1] document for further information.

Figure 3-6: Liberty architecture

Single Sign-On and Identity Federation

The first time that users use an identity provider to log in to a service provider, they must be provided with an option to federate their existing local identity on that service provider with the identity provider. This allows the identity provider to use the user's federated identity in a confidential manner for single sign-on purposes with service providers within the same circle of trust. This is explained further in this section in conjunction with Figure 3-7.

Figure 3-7: Identity federation between an identity provider and a service provider

In a federated identity system it is essential that users must be uniquely identified and asserted across all service and identity providers. A quick solution that comes to mind is the use of a Global ID (global identifier). However, implementing global identifiers that are not provider specific and are "portable" across services is a significant challenge. Furthermore global identities pose risks—if they are compromised, malicious users can gain access into virtually every provider in the federation.

As an alternative to global identifiers, Liberty employs explicit trust relationships that are created when a user decides to federate his/her identity between an identity and service provider. When federating a user's identity, opaque handles (also know as name identifiers) instead of actual account identifiers are used to uniquely resolve users. An explicit trust relationship is created when the user chooses to federate his/her identity the first time a user logs in to a service provider using an identity provider. Figure 3-7 illustrates the creation of handles.

As shown in Figure 3-7, upon identity federation, the user directories of the identity provider and the service provider make use of opaque handles to reference the user account on either provider. In this way, the real identity of the user is concealed and the usage of a specific alias is restricted only to this link as other links may use different aliases. This mechanism securely establishes a federated user identity without the use of a single global identifier.

Federation Scenarios

Based on the federated identity mechanism discussed in the preceding, it is possible to realize three useful scenarios.

Federating Single Identity Provider, Multiple Service Providers A user may use a single identity provider to access multiple service providers. To allow the service providers to exchange information about the user, the user must explicitly federate the two service provider identities. The following hold true in this scenario:

• Service providers cannot directly exchange information about a user identity federated through an identity provider. The service providers may only communicate with the identity provider individually.

• The identity provider holds individual/isolated relationships with each service provider (through separate user handles), thus ensuring privacy and confidentiality of user information.

• User can sign on to multiple service providers using a single identity provider.

Federating Multiple Identity Providers, Single Service Provider A user may use multiple identity providers to access a single service provider. A federated identity between multiple identity providers and a service provider can be very useful if a user requires access to a designated service from multiple locations. For example, when a user switches from a corporate intranet to the Internet, or to a mobile device, the user may typically use different identity providers, each within a different circle of trust in order to access the service.

Federating Multiple Identity Providers In order for the user to avoid having to "remember" to federate a new service with multiple identity providers a user may federate identity providers together allowing them to access each other's information. Thus when a new service is made accessible to a primary identity provider, all other identity providers privy to that information may be used to access the service. When a user's identity is federated across many identity providers, an explicit link exists between each identity on different identity providers, forming a trust chain. Providers cannot skip identities in a trust chain to access services or request information because user identity must be checked at each step.

The following are issues and risks are associated with federating identity providers:

• Liberty protocols do not dictate the underlying semantics of federated relationships. Reasons for not doing so could be due to the variable factors that often drive the design and implementation of such semantics. Such factors may include organizational agreements between providers, capabilities of the Liberty implementations deployed, political influences, and legal liabilities.

• How trust relationships between identity providers are established, and how those relationships are represented to service providers, are unspecified. Organizations that host identity providers must define policies that govern such trust relationships and the means for representing them.

• Agreements and policies that govern circles of trust must also address how federation failures are communicated to users.

• Creating several local identities with many service providers and/or identity providers and then federating them constitutes a security risk when identity providers possess reusable user credentials such as a username and password. Such reusable credentials can be used to impersonate the user at every service provider federated with that account.

The Liberty approach is more secure than a global identifier in the following ways:

• If an identity provider in a circle of trust is compromised, the rest of the members in the trust circle need to just record the incident and "sever" links to that provider to re-establish secure access. Since the identities compromised at that provider are only useful to access other providers at adjacent links, only the adjacent providers need to be cleansed of any reference to compromised identities. In contrast, if a global unique identifier is compromised, every provider in the circle of trust is affected, and hence recovery becomes a more arduous task.

• In the Liberty network identity architecture, information about a user may be "spread-out" over multiple identity providers in a trust circle. Hence if a provider is compromised, only the user information at that provider is exposed. In contrast, if a global unique identifier is compromised potentially all personal information of a user may be exposed, which constitutes a serious privacy violation.

Defederation

Users have the ability to terminate federations, or defederate identities. Defederation is the process of terminating the validity of a federated identity at a service or identity provider. The defederation process may be initiated at the identity or service provider. When defederation is initiated at an identity provider, the identity provider is stating to the service provider that it will no longer provide user identity information to the service provider, and it will no longer respond to any requests by the service provider made on behalf of the user. When defederation is initiated at a service provider, the service provider is stating to the identity provider that that user has requested that the identity provider no longer provide the user identity information to the service provider and that the service provider will no longer ask the identity provider to do anything on behalf of the user.