Securely extend Active Directory’s reach into the cloud
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.
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.
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
An SAML token is in fact called an assertion. The payload of this assertion contains a potentially far broader set of identity information, called claims, than a Kerberos ticket holds. An SAML token is designed to be much more flexible in this regard. A claim can be anything you define it to be: name, email, phone number, age, privilege level, meal preference, etc.
In AD, a Kerberos ticket has time restrictions regarding when it can be used. This prevents replay attacks, in which packets are captured then played back to a server at a later time in an attempt to compromise it. An SAML assertion also contains conditions that place more stringent restrictions on when the assertion is valid than the Kerberos protocol is capable of doing. You can restrict when the assertion is valid, who can use the assertion, how many times it can be used, and whether the assertion can be delegated. Thus, an assertion can be highly targeted toward a specific use, and that use only, to increase the security of the authentication process.
Finally, an AD Kerberos ticket is encrypted with either the ticket-granting server key (for a ticket-granting ticket—TGT) or the user key (for a session ticket). An SAML assertion is signed and can have various degrees of encryption from the identity provider that created it, from individual components to the entire assertion. The signing ensures that the assertion is indeed from the stated identity provider and hasn't been tampered with, and the encryption ensures that the assertion hasn’t been spied on.
For all these similarities, though, here’s the most important distinction: The scope of an AD Kerberos ticket is essentially within the enterprise, whereas an SAML token has no restrictions of this kind at all. This means that a claims-aware application can authenticate users equally comfortably inside or outside the corporate firewall.
This token doesn’t appear out of thin air. Something has to create it, and AD doesn’t know anything about this process. Enter yet another component of the claims world: the Security Token Service. The STS issues tokens on behalf of requests from users. Figure 2 shows how an STS interacts with a user and AD to build a token that can be presented to claims-aware applications. Note that Figure 2 explicitly shows the user’s browser. This is because it can be closely involved in the process if the user’s OS doesn’t have a client that understands the token-passing process.
Figure 2: STS token-creation process
Now that I’ve introduced all the players involved in claims-based authentication, let’s take a look at how all these components work together to authenticate a user to an application. It’s kind of a complicated dance, but it’s almost entirely transparent to the user. Because of federation’s flexibility, federated identity is used in several different scenarios. In this article, I focus on just the two most likely scenarios you’ll face. In these scenarios, you must first set up a federated trust between your federation service and the service provider. This necessary step lets the service provider’s STS decrypt the encrypted claims coming from your company’s federation service; it also lets your STS accept claims requests from the service provider.
The first scenario occurs when a user inside the enterprise attempts to access a claims-aware application that’s also inside the enterprise. This situation might not exist in your organization today, but it will be common in the near future as more applications become claims aware and as the private cloud becomes more popular.
The process of an internal user accessing an internal application includes many individual steps, as Figure 3 shows. However, this scenario is easier to understand if you keep in mind the high-level process.
Figure 3: Internal user accessing an internal application
All you need to implement this scenario is a federation service, such as Active Directory Federation Services (AD FS) 2.0, IBM Tivoli Federated Identity Manager, or Ping Identity’s PingFederate, and a claims-aware application such as Microsoft SharePoint 2010.
In the second scenario, which Figure 4 shows, the user is inside the enterprise and needs to access an external web-service provider. There are two major use cases for this scenario. The first use case is accessing an SaaS provider, in which an enterprise uses a service such as Salesforce, Google Apps, or a hosted email provider without maintaining separate passwords at every provider. The second use case is for B2B collaboration, in which users in the identity provider’s enterprise need to seamlessly collaborate with users in another enterprise who have documents to share. In this case, the claims-aware application might be SharePoint, which would let users from both enterprises post and work with documents. This overall scenario is broadly known as Internet single sign-on (SSO). Note that in this scenario, the user isn’t actively doing anything, and no applications on the local computer are aware of the web service; the user’s browser is simply redirecting all the traffic through it. This is what’s known as a passive client.
Figure 4: Internal user accessing an external application
The single largest difference between this scenario and the previous one is that the service provider has its own STS, and the application service trusts it alone. The federated trust agreements that the service provider establishes with its customers are supported by the STS, rather than the application service. This service provider configuration is more scalable than one without an STS because the resource load of potentially thousands of trusts is focused on the STS instead of the application service and won’t affect the application service’s resources. It’s also more secure, because the application service doesn’t trust any external claims—only the claims generated by its own STS.
The passive client and the addition of the service provider STS add several steps to the process. Instead of the client actively participating in the authentication process, the application service redirects the request through the client’s browser to the service provider’s STS to discover the needed claims (step 3). Then, the service provider’s STS sends a token request to the identity provider’s STS (step 4). After the identity provider’s STS generates an SAML token, it redirects the token through the user’s browser (neither the user nor the browser has any idea what’s going on) to the service provider’s STS. This STS will verify it, generate a token with its own signature (the only one the application trusts), and present it to the application service (step 7). The process then completes as expected, and the user is redirected to the application to successfully use it. For more information about claims-based authentication in SharePoint 2010, see SharePointPro Connections, “Understanding Claims Based Authentication in SharePoint 2010”, as well as Steve Plank’s whiteboard video presentation “How ADFS and the Microsoft Federation Gateway work together up in the Office 365 Cloud”.
Note that the service provider isn’t required to have an STS of its own; the application can directly trust the identity provider. However, this situation might be more common in the B2B collaboration use case, where scalability isn’t an issue.
Federation also works if the user in the second scenario is outside the enterprise (e.g., working from home on a nonwork computer without a VPN). Because the user is outside the Kerberos domain, the employer’s STS puts up a forms-based authentication page for the user to directly enter enterprise credentials for authentication. After the user is authenticated, the claims-based authentication sequence continues.
Now that you’ve seen how some of federation’s moving parts work, you might wonder whether anyone has gone to the trouble to implement it. The adoption of federation technology was slow in its early years because few companies saw the ROI for internal applications and the occasional external collaboration. It took cloud computing, an increase in the number of claims-aware applications, and the explosion of SaaS providers to really give federation the boost it needed. You’re already using it today; you’re just not aware of it. (Which, after all, is what federation is all about; if it’s doing its job, you shouldn’t notice it.) If you use any web services that require Windows Live ID, such as TechNet, MSDN, Windows Live Messenger, or any of the other Windows Live properties, you’re already using federated identity in the consumer space.
Many companies are implementing federation to keep pace with their users’ demands to use SaaS services in a secure and scalable manner. If you set up a federated trust with the provider, your users can log on to the service using their own user IDs and passwords—they don’t have to create and manage a separate account; it’s handled automatically. The enterprise’s account management team no longer has to worry about managing duplicate accounts for multiple SaaS providers—especially the important security task of deprovisioning accounts that shouldn’t be active. And after you set up your federation environment with your own STS, it’s a trivial task to add new trusts as you acquire new service providers and applications.
Who are the major vendors in federation and Internet SSO software? Microsoft is certainly one of them. AD FS 2.0 is a free download for Windows Server 2008 R2 or Server 2008. It does a good job, but it’s not a trivial implementation; you’ll want to work through the TechNet documentation and step-by-step guides in a lab environment first. Along with AD FS, Oracle Identity Federation, CA Federation Manager, and Ping Identity’s PingFederate comprise the majority of the enterprise Internet SSO market.
There’s another class of federation software that sidesteps the need for a local STS installation. Products such as Ping Identity’s PingConnect, Symplified, and Okta make federation itself a cloud service. The companies host federation software and manage trusts with a vast number of SaaS vendors so that subscribers to these services automatically have secure access to the vendors.
A fairly small percentage of SaaS vendors accept federation today, but the number is rapidly growing. As federated identity becomes common between enterprises and cloud service vendors, the idea of using claims-based identity for applications inside your company won’t seem nearly as radical as it does today. A benefit of claims-aware applications is that they can coexist peacefully with your existing Kerberos-based infrastructure and applications because the STS translates the Kerberos identity information into claims for the applications. Think of the STS as a proxy or gateway between the Kerberos world and the claims world.
The growth of the market for internal claims-aware applications (enabling traditional applications and creating new ones) is a chicken-and-egg situation. ISVs don’t want to invest in making applications claims-aware until there’s a good customer demand for such applications. But customers won’t generate much demand until they’re equipped to support these applications with a federation service and can use this form of authentication with little added expense. What will tip the market into broad adoption is the SaaS scenario that I discussed; companies that add federation capability to support their SaaS vendors are positioned to begin using claims-aware applications internally. To help drive this cycle, you should insist that your SaaS vendors provide federation capability. It reduces the risk for you, increases your visibility into the cloud, reduces the vendor’s need to maintain an identity store, and helps to position your business to handle claims-aware applications.
The best way for you to get started in understanding federated identity is to start playing with it yourself. Set up a federation service in your lab. (I’ll write about my experience installing AD FS 2.0 in my own lab in my June Enterprise Identity column.) Start the project to add a federation service for your company. Approach your company’s Information Security team first to gain support; if your security administrators aren’t already aware of the risk posed by having separate accounts for every SaaS vendor, you should make them aware. A federation service will lower your company’s security exposure by decreasing the number of duplicate accounts with SaaS vendors, decreasing overhead costs if IT is attempting to manage these duplicate accounts, and making life easier for your users with fewer logons to remember. If you don’t want to host a federation service yourself, federation-as-a-service products such as PingConnect, Symplified, and Okta will outsource it.
Federated identity is a key enabler to integrating cloud services and on-premises traditional IT services. At the moment, cloud computing’s hype outstrips its current use—but don’t mistake it for only a fad. Virtualization, the web, and the Internet itself all went through these cycles, and they’re an accepted part of our infrastructure today. It’s time to begin adding federation skills to your career toolset. Federation’s importance will only grow in the future, and these skills will be crucial to both your company and your career.