The Strands of Your Identity Web

One of the challenges that identity professionals face is that they rarely have to deal with just one identity system, such as Active Directory (AD). No, there's usually quite a collection of systems that provide identity inside your company, and often part of your job is to somehow tie all these systems together in some coherent manner for your applications to use.

And that's just for on-premises systems. With the dramatic increase in Software as a Service (SaaS) solutions, the number of applications that need identity information has grown far faster than most IT shops' ability to securely provide it. A successful identity professional needs to be able to link multiple identity providers of different types with all these services or applications—think of spaghetti strands—to provide a web of identity. Once that web is constructed, you must keep the flow of identities around the web working; it’s a process a former colleague once described as "keeping the spaghetti wet." This month, I thought I'd look at some of the biggest nodes in this identity web, and where their spaghetti strands connect with one another. You might not have all these strands in your environment, but you certainly must deal with most of them, and there are also some that you should consider for your company's future.

Figure 1 shows these components and the typical data flows between them. This figure isn't intended to represent a production environment; for example, the identity provider federation service wouldn't have inputs from both a virtual directory service (VDS) and AD, because the point of a VDS is to minimize identity connections. The idea is that you can look at each node and see what its typical inputs and outputs are.

Figure 1: An Identity Web

Active Directory

AD remains at the base of most companies’ identity infrastructures. It’s a ubiquitous identity source in the enterprise. Around the world, AD is installed in (or is the central directory for) over 75 percent of companies with more than 500 clients. And it’s slowly evolving to meet the needs of modern applications and services; Windows Server 2012 AD will support virtualization with no caveats, and it will introduce basic claims support. AD is the one application that any identity and access management (IAM) application must deal with, thanks to the sheer amount of investment in it and AD-integrated applications, not to mention its associated hardware, software, and process infrastructure. Add to that the widely held belief that identity should stay on premises, and you can see that a currently installed, on-premises AD implementation isn't going anywhere in the foreseeable future. AD is usually the source for a company’s unique identities, such as security groups and computer accounts, but other objects (e.g., userIDs) and attributes (e.g., employee numbers) typically come from an "upstream" HR system.

Other Identity Sources

AD's widespread use, however, doesn't mean it's the only identity source. HR systems are truly the most widely found identity stores in business; you can't keep track of employees without one. Due to their sensitive nature, HR databases tend to be upstream of other identity stores and don't commonly accept updates from them. Other sources—such as physical security databases that contain unique badge IDs or custom applications—might have their own unique identities with varying degrees of communication to an AD instance.

Metadirectory Services

Metadirectory services evolved as a way to aggregate objects and attributes from a wide variety of identity sources into a comprehensive metadirectory (sort of "one directory to rule them all," if you don’t mind the Lord of the Rings analogy), which then updates these sources and other applications with the data they require. The value proposition of a metadirectory service is that when you use one, you can theoretically put any attribute from one identity source into any other, or make it available for any application. But that’s generally not a simple task to accomplish. Due to their cost of implementation and support, most metadirectories are found only in large enterprises. They fit right in the middle of the on-premises identity web, tying both identity sources and identity consumers together.

As I talked about in my March column, “The Rise of Virtual Directory Servers,” a VDS is another way to present an aggregate view of objects and attributes from different identity sources. Instead of pulling identity data on a scheduled basis from these sources into a single large identity metadirectory, then pushing data out to a variety of locations in case it's needed, a VDS creates a view into these identity sources. This view, which appears to the application as a single directory, is really an abstraction. (Whenever you see the word virtualization, you should think "adding a layer of abstraction," or "smoke and mirrors," if you prefer.) When an application makes a query to this interface, the VDS makes queries in real time to the necessary identity sources (minus some sophisticated caching techniques) and returns the data to the application. Because of the abstraction layer the VDS provides, the application doesn't need any fancy logic to determine to what source it needs to go to get attributes. VDS solutions are popular because they’re much simpler and cheaper to deploy than metadirectory services; they fit into the identity web between your company's identity sources and applications that need to use those sources.

Many companies have well established web access management (WAM) systems that any new identity solutions must integrate with. WAM solutions provide authentication and authorization from one or more identity sources for both internal and externally facing web services. The best-known use case is providing external access to a web service that resides on a corporate firewall. These on-premises systems are tightly integrated with multiple identity sources and don't commonly use newer technologies such as VDS to simplify their integration.

Directory synchronization services have become a common solution when there's a need to duplicate identity data from an enterprise identity store to a cloud service provider. A descendent of the metadirectory server's synchronization engine, a directory synchronization service is a lightweight process installed on a server that monitors an identity store such as AD for changes, and replicates those changes immediately up to its owning cloud service. This is generally a one-way synchronization; the cloud identity store mirrors the contents of the on-premises identity store, or a designated subset such as an organizational unit (OU) or security group. Directory synchronization is used by SaaS solutions such as Microsoft Office 365 and Google Apps. Directory synchronization is also used by many Identity as a Service (IDaaS) providers to populate their identity store. Passwords might or might not be synchronized with the cloud identity store, depending on the vendor and type of configuration you choose.

Federation

The last major component of the on-premises identity web as it stands today is the federation service. This service stands as the bridge between shared-secret security protocols such as Kerberos (used in AD) and claims-based protocols such as Security Assertion Markup Language (SAML—used for claims-aware applications). A federation service transforms tokens between different security domains and is an important piece of the web connecting you to cloud applications. In the identity web, federation services are connected to one or more identity sources and provide tokens to claims-aware applications on premises or to service providers in the cloud.

But federation doesn't necessarily have to be on your premises. You can outsource your federation service to an IDaaS provider, which provides an intermediary that takes care of authentication and authorization to a wide variety of SaaS applications. Most services will also provide single sign-on (SSO) to service providers that don't support federation through their own proprietary methods.

Whether you work for an identity provider or a service provider depends on your viewpoint, of course. Although most of you probably support internal IT systems, a service provider that has a standalone identity store (e.g., separate accounts created on the service provider's site) for the users of its service is also an identity provider. And an enterprise identity provider that makes an application available for its business-to-business (B2B) partners is also a service provider.

If this situation weren’t already complicated enough, other identity providers are entering the identity mix as well. Many consumer sites use Facebook, Google, Twitter, Yahoo!, and others to provide SSO; in the future, these providers will see more use in the enterprise (e.g., to provide SSO for customer service portals).

Look Forward

It's important to keep your existing systems running well, but it's equally important to look forward. You need to position your identity web to take advantage of these new technologies where it makes business sense. And the business case is sometimes based on a combination of factors such as information security and savings to individual departments—for example, moving from grass-roots, departmentally managed accounts for SaaS providers to a centrally federated approach.

Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.