Everything is federated these days. In some cases, particularly when it is waved at a problem, the F-word is not well defined. In other cases there are clearly defined semantics for the word federation. Federated authentication is one of those cases.
The Enterprise Authentication Model
In the late 1990s, the purpose of authentication was to establish a security context using technologies such as GSS-API (Generic Security Service Application Program Interface), SASL (simple authentication and security layer), or TLS (transport layer security) between two endpoints of a communications channel together with identifiers that represented users. Back then authentication involved two parties: the client and the server.
In this model, which I’ll refer to as enterprise authentication model, the user identity and the user identifier are one and the same. Using a directory service-often one based on LDAP (Lightweight Directory Access Protocol)-the server uses the user identifier to look up additional information about the user. For example, an IMAP (Internet message access protocol) server might store information about user mailboxes in the directory keyed by the user identifier that is used in authentication with the IMAP server. Simply put, the IMAP server can pull information about the user from a directory by using the user identifier as a lookup key.
This model still works well within a single organization and with a single directory. The success of products such as Microsoft Active Directory provides ample evidence that within the enterprise community, this model is alive and well today.
The limitations of the enterprise authentication model arises when organizations need to deploy shared (often business-to-business) applications or when they attempt to merge enterprise directories as a result of corporate mergers or acquisitions. Arguably the failure of the enterprise model to handle cross-organizational authentication deployments has been the result of the failure of LDAP to provide a scalable, vendor-neutral way to authorize secure access to protected data. The risks involved with allowing external access to critical enterprise directory data is typically viewed as unacceptable.
The Rise of SAML
As relationships among enterprises, service providers, and users became more interdependent, the challenge of obtaining lookup permissions from outside of an organization grew. In this new world, in order for a service in organization A to be able to accept users from organization B, the service in organization A needs permission to look up users in organization B’s directory. Even if the number of organization A’s and services is small, the problem of controlling access to organization B’s directories quickly becomes unmanageable.
Initially the solutions seemed to focus on Web applications (for the most part, they still do, though that is starting to change). Toward the end of the 1990s, the need to manage centralized authentication for Web applications drove the development of the so-called enterprise Web single sign-on solutions.
Out of those solutions a number of open-source and commercial options evolved, many of which relied on the management of HTTP cookies. Those solutions were also intraorganizational in nature and, as the need to connect Web SSO (single sign-on) products across organizational boundaries grew, there arose a need for a standardized protocol for communication authentication information between applications.
In January 2001, the OASIS Security Services Technical Committee (SSTC) convened to begin work on what became SAML (security assertion markup language), a technology that has become one of the cornerstones of federated authentication.
SAML can support several use-cases but the most commonly deployed pattern is called Browser Web SSO. This particular profile of SAML involves three actors: the user, the identity provider, and the service provider. SAML uses XML-based messages and relies on public key cryptography (although not necessarily on public key infrastructure [X.509] or PKIX) to sign and encrypt those messages. In a typical authentication flow the user presents credentials to the identity provider (IdP), thereby proving her identity to the IdP. The IdP then gives the user a SAML message called an assertion, digitally signed with the key of the IdP and optionally encrypted with the key of the service provider. The assertion can be thought of as a sealed envelope containing a statement to the effect that the user has successfully authenticated herself as well as the properties of the user the IdP wants to make known to the service provider. If the service provider trusts the public key of the IdP, the service provider is able to consume the assertion. The assertion often contains an identifier of the user and-more important-additional attributes associated with the user, relieving the service provider from having to conduct additional lookups in directories.
In the SAML federation model, identity information-identifiers and additional attributes-is pushed from the IdP to the SP. Conversely, enterprise authentication operates according to a pull model. This might seem a small difference but it fundamentally changes the way applications (service providers) consume identities.
At this point, the astute reader will undoubtedly ask: “But what about key management?” Indeed, key management is the core of the matter. Some federations still rely on traditional PKIX-style hierarchical PKI for key management. Others, including many large-scale SAML federations, rely on an alternative key-management method. In this method, collections of keys are collectively signed, resulting in an object that behaves like a combination of a PKI certificate and CRL (certificate revocation list). Incidentally, this bag-of-keys model has been considered by the KARP (Keying and Authentication for Routing Protocols) working group as the basis for routing protocol key management (albeit in that case using symmetric keys).
Common to all approaches to key management is a federation that consists of those identity providers and service providers that share trust in a set of keys. Such a trust framework is called a ring of trust. The deployment of OpenID typically relies on a single global ring of trust that encompasses all OpenID IdPs, and SPs. In fact, it is entirely possible that the success of OpenID is due in large part to the absence of a requirement on key management. Conversely, SAML federations often do require key-and-trust management, which constitutes a major part of the work involved in running a SAML federation.
SAML has seen large-scale deployments in the research and education (R & E) sector worldwide. The Trans-European Research and Networking Association (TERENA) conducts an unofficial census of R & E federations through its REFEDS activity, which places the number of R & E federation users at somewhere around 10-12 million per month in the leading countries in Western and Central Europe and in the United States alone. These figures will undoubtedly grow rapidly in the next few years.
Examining Alternative Technologies for Building Identity Federations
Identity federations have been successfully built using other technologies. One of the largest such deployment is the eduroam federation, which uses Radius and EAP (extensible authentication protocol) to provide access to wireless networks (using 802.1xZ) on hundreds of university campus networks across the globe. The success of eduroam demonstrates that the driving force behind federated authentication is almost always the need to share resources across organizational boundaries.
The IETF has been mostly absent from this field but that may soon be changing. IETF 77, which was held in Anaheim, California, in March 2010, saw its first Moonshot project bar BoF session (An informal birds-of-a-feather (BoF) session). The aptly named project, which is partly funded by JANET and by theGEANT3 project, aims high but the potential benefits justify the effort. It brings together a wide range of IETF standards including EAP, GSS-API (generic security service application program interface), and Radius together with SAML to construct a federation framework that may provide many current IETF protocols, including SSHv, NFSv4, and IMAP, access to federated identity. If successful, it would extend identity federation beyond Web-only applications, but it would also provide a general trust-framework for the Internet.
Other work related to federated authentication that might end up being done in the IETF address alternative approaches that have been proposed to bridge Web-centric identity (such as SAML or OpenID) and SASL.
The driving force behind a lot of these efforts is the need to federate messaging, calendaring, as well as virtual worlds protocols, which are some of the more important examples of applications where the browser isn’t the obvious choice of a client. The needs of the mobile market and its focus on apps may well turn out to be a boon for federated identity. While HTTP is often used as a protocol layer, typically through RESTful2 service calls, the client is not always a browser in the traditional sense.
Some of the efforts described here have one foot in the IETF and one foot in other standards-development organizations. Some of the work is in even more loosely organized groups of volunteers. There is a huge potential for the IETF to become (and stay) involved in this process but it will require a certain amount of agility on the part of the IETF to keep on top of the changing landscape.
This article was posted on 26 June 2010 .