For the first time in a long time, the enterprise identity landscape is evolving at its most basic level. There’s a new kid on the block, and its name is federated identity. Although the seeds of this change have been around for a while, we just didn’t recognize its importance. Federated identity is here to stay, and IT professionals and developers need to learn about it and how it will affect their work in the future.
Why We Need Federated Identity
To understand the growing popularity of federated identity, it helps to look at the challenges that IT professionals and developers face when using traditional identity authentication in the modern IT environment—in particular, the Kerberos protocol. The point behind an identity provider, such as Active Directory (AD), is to centralize identity information for resources to consume. Although identity-oriented IT pros tend to lose sight of it, the purpose of the authentication process is to determine and validate the user’s identity in order to gain access to resources.
The Kerberos security protocol (and therefore the AD domains and forests built on it) was designed to work in a fairly secure environment, such as a corporate intranet. The Kerberos protocol, as implemented in AD, provides two components: confirmation of identity and security group membership. If a resource (e.g., a DFS namespace) requires more information, such as site information, it needs to extract that information from another location—AD itself.
However, scenarios that don’t require any modification of AD to store more information are pretty simplistic in real life. Microsoft Exchange Server, for example, requires more information about a user than the base AD schema provides. So, AD admins must extend the schema to allow Exchange to store added identity data about its users. Schema extensions aren’t done casually; they take time to prepare for and schedule. As a result, other applications might choose to store identity information in databases such as SQL Server or Active Directory Lightweight Directory Services (AD LDS) that don’t require the amount of preparation a schema change does.
But what if the users and resources are in two different enterprises—for example, a joint venture or collaboration, or for a Software as a Service (SaaS) cloud application? Do you create and manage the external users’ identities by creating shadow accounts in AD, or do your developers create a separate account database to hold them? How do you keep up with the accurate provisioning and deprovisioning of these accounts? What about providing adequate security for these identities against hackers?
Most companies don’t want to manage external users’ identities and the headaches that go along with that management. If an application is intended to support multiple access scenarios, developers must build in multiple authentication mechanisms. Identity design and management in these and other scenarios become very cumbersome, and the traditional model is stretched to its limit.
What Federated Identity Is
The federated identity model can handle a variety of scenarios. Federated identity is the ability to port data across security domains using claims and assertions from a digitally signed identity provider. To understand what that definition means, let’s break it into parts. As I described in the previous section, each enterprise’s identity store can be generically described as a security domain, regardless of whether it’s using AD or some other directory product. For the purpose of this article, AD is the identity provider for scenarios inside an enterprise. For scenarios that span multiple enterprises, the identity provider is the entire enterprise that provides identity information (not just AD). As for claims and assertions, these are essential parts of what we call claims-based authentication.
Claims-based authentication is the cornerstone of federated identity. At its simplest, claims-based authentication is about presenting an application with the potentially wide variety of identity information it needs, from an identity provider it trusts, in a highly secure envelope, regardless of whether the application is inside or outside the enterprise. That’s why it can handle the two-enterprise and SaaS scenarios that I discussed in the previous section so well. Claims-based authentication adds flexibility and security, whereas traditional authentication technology gives you either flexibility (LDAP queries to AD) or security (Kerberos).
The claims-based authentication model is based on a few simple, intuitive concepts, but the authentication process can bounce back and forth quite a bit. Let’s compare some of the basics of this model with one you know a little better: the Kerberos protocol.
In AD, every authenticated user has one or more Kerberos tickets that contain identity information. A basic construct of claims-based authentication is the token, formatted in Security Assertion Markup Language (SAML). Figure 1 shows an SAML token, which is similar to a Kerberos ticket in many ways. A Kerberos ticket contains a payload, called the access token, that asserts what security groups the user is a member of. The resource (e.g., a file server) trusts this assertion, because the ticket is cryptographically confirmed to be from a valid identity source—which in AD is the Kerberos Key Distribution Center (KDC) of the domain controller (DC) the file server is talking to.
Figure 1: SAML token