An Introduction to Identity Management

[Michael.Santarcangelo]

An Introduction to Identity Management
David Stern, CISSP

Introduction
Depending on where you sit, Identity Management (IDM) is irrelevant, a holy grail, or a complete boondoggle. Having experienced all three situations at one time or another, and more recently seeing it actually work; I think it’s a good idea to demystify the subject matter. In this article, we will cover the conceptual framework of Identity Management, and touch on some of the more important terms and methodologies.

Let us start out by defining an Identity. Your average enterprise uses a mix of Windows, UNIX, Mainframe, databases, applications, and networking elements. Each of these requires user interaction, which starts with a login and a password. These credentials authenticate you to the system and then determine what you are authorized to do. Your digital identity therefore must encompass authentication and authorization information, as well as “white pages” type information (phone number, address, title) that tie it back to the physical world. When a user presents his credentials to a system by logging in, it is known as “asserting credentials.” In the perfect IDM world, all of this information is stored in a single, universally accessible directory, sometimes known as a Meta Directory.

Single Sign On (SSO) is IDM’s close cousin. In an SSO environment, a user only needs to assert his login credentials once. After that, every system and application would automatically allow him access based on his one time identity assertion. Obviously, to make this work, every system in scope needs to share the same credential store, making IDM a virtual requirement.

The business drivers for Identity Management are quite compelling. Identity Management at its highest level is a conceptual framework from which an individual’s login credentials or identity is centrally managed. Outside of this framework I would need separate credentials for every server, PC, network device, web page and application that I use on a daily basis. That could amount to dozens of accounts that need to be managed individually. Inside of an Identity Management framework, my identity is created and access rights are established in one stroke. The same thing happens when my identity or rights need to be removed.

For the sake of IT newcomers, I will state that this works nicely on paper, but in reality has hurdles as high as K2. Until recently, systems have been written with no thought of commonality. Going back and rewriting or re-architecting enterprise systems can be compared to trying to change the tires on an Indy car flying down the straight away. However, the pain of distributed management was significant enough to push the industry to address the problem. Identity Management was born from this pain.

Interim Solutions
Before we delve any deeper, we should take a moment to acknowledge three “interim solutions” to the IDM problem that have supported IT for many years. Each of these solutions was designed to support centralized credentials for a specific class of system.

NIS – Network Information System or “Yellow Pages” were developed by Sun over 10 years ago to allow UNIX systems to share a common password store. NIS helped solve many password management issues, but it was plagued by inherent security issues.

TACACS – TACACS was developed as a central authentication method aimed at network devices. In an organization with hundreds of switches and routers, local account management that meets security standards can become impossible. TACACS solves this problem nicely.

Active Directory – AD evolved out of the primordial soup that was the Microsoft Domain model for NT. Every Microsoft desktop and server operating system, as well as server and desktop applications can use AD for centralized authentication. Microsoft’s industry dominance means that almost every organization (large and small) runs AD. In the past few years, Microsoft has opened AD to many other systems, allowing organizations to leverage their AD credentials for other systems. A good example of this is TACACS.

Each of these solutions provides sufficient coverage for most enterprise technology silos. But there are still applications and systems that either do not or cannot use one of these technologies. These solutions also do not include the work-flow processes involved in assigning roles, provisioning/de-provisioning accounts, auditing, and approving changes. IDM solutions provide this centralized management layer. The IDM world looked to an open standard known as LDAP to get closer to full interoperability.

IDM and a Reality Check
Lightweight Directory Access Protocol or LDAP is an open standard designed to allow applications to query directories in a common way. An LDAP directory will have a known hierarchy based on other open standards that provides the greatest chance for application or a system to understand where data is located. LDAP is so widely accepted that most operating systems and programming languages have built-in support for it. Microsoft Active Directory is itself a limited LDAP directory and most flavors of UNIX and Linux have direct support for LDAP.

The same mixed environment that relies on directory silos for each class of operating system looks much different when LDAP is introduced:
•   Active Directory (AD) ties together Windows servers, desktops and email. Most of the leading LDAP directory solutions such as Sun One and Novel eDirectory can synchronize with AD.
•   TACACS can use AD for an authentication source creating a common login for Windows and network elements.
•   UNIX/Linux systems ties into the LDAP infrastructure. Since the LDAP is synchronized with AD, UNIX/Linux logins will be shared with Windows and network elements.
•   The popular .Net application language makes integration with AD simple. Applications that take advantage of this integration can also share a common login.

This interoperable LDAP architecture looks great. It clearly shows that most technologies found in the enterprise can share a common source for credentials. In reality, a combination of politics, lack of technical vision, and many other common obstacles stifle this potential. Enterprises are still left with plenty of critical systems that are marooned on their own separate islands.

The three most common types of systems that do not utilize common directories are custom applications, web based applications, and infrastructure such as operations systems or database systems. For each of these, the IDM community has attempted to devise solutions.

Custom Applications: Almost every industry has unique computing needs that the mainstays of IT (IBM, Microsoft, Cisco, Oracle, Red Hat) cannot address with their mainstream offerings. This leads organizations to create their own applications that rely on custom databases and schemas for authentication and authorization. The most common solution for a single identity comes from the Single Sign On (SSO) community. The usual solution involves installing an agent on each workstation that is programmed to capture login credentials from a known centralized directory such as LDAP or Active Directory. When the custom application is invoked, the agent will detect its login prompt and automatically fill in the credentials. While this methodology does not address back-end integration, it does allow for a common login for day to day activities. A more expensive and complicated solution is to write custom database connectors that allow an IDM solution to tie into the application’s proprietary database. While this approach covers more of the problem, the cost will usually make it undesirable.

Web Based Applications: The web has become the premier application delivery platform for its common interface and ease of development. Most custom web based applications share the same design deficiencies as their client-server brethren in terms of proprietary credential stores. From an IDM perspective, web based applications are much friendlier since they are designed with common security mechanisms such as session cookies.

A whole class of solutions knows as WebSSO have evolved to address this challenge. A WebSSO architecture fronts one or many web applications and accepts identity assertions. The WebSSO module hooks into a common directory, authenticates the user, and then passes that information back to the web based application. The solution is not cheap, but it allows an organization to tie dozens of disparate web based applications together with a single identity.

Infrastructure: In many organizations, the political divides run so deep that IT groups will never change to share a common directory. The IDM community takes a brute force approach to solve this problem. IDM solutions such as CA ETrust Admin use agents that can deploy and manage identities. They also create ODBC connections to remote proprietary databases. These mechanisms keep identities synchronized by detecting and propagating changes across every diverse infrastructure element. The solution is fraught with obstacles, but with time, money, and a mandate, it eventually corrals operating systems, applications, and infrastructure, forcing upon them a centralized identity.

Meta Directories and Federation
Mergers and acquisitions tend to grow IT organizations horizontally. Companies such as Johnson and Johnson or Proctor and Gamble may have dozens of divisions that developed as the result of such activity. The challenge of integrating processes and personnel is big enough without trying to force a common directory environment. In these cases, the Meta Directory shines. As we mentioned early, today’s LDAP products are incredibly flexible in their ability to synchronize with AD, Novell, and other LDAP directories. By leveraging this capability, an organization can maintain a common Meta Directory that contains information from every business unit, without ever changing the way that business unit operates. Something as simple as a company Whitepages can scale very easily to include new divisions using this method.

The Meta Directory also plays a leading role in the ever widening use business partner connections. An uncontrolled laughing fit results when one organization suggests that a partner organization share access to their AD. The security model is weak at best, and no CIO will stake his job on this working. In most cases, partner access requirements results in a manual process of creating common logins and building virtual private networks. The administrative costs can sap some of the value of the partnership.

Meta Directories can solve this problem through a methodology known as Federation. Just as LDAP can be used to synchronize with diverse internal directories, it can do the same thing for external directories. LDAP’s implementation is widely understood, has been vetted for over a decade, and its security model is clean and robust. When compared to Active Directory, establishing an LDAP to LDAP connection is trivial, and carries none of the security stigma of AD. Outside of an LDAP Federation framework, partner access to external or internal applications requires a workflow to handle provisioning and de-provisioning of local AD accounts. Inside of an LDAP Federation framework, the external partner would identify which of its users should have access to the applications, and that information is passed through the IDM infrastructure.

Conclusion
Identity Management and Directory Services are probably one of the least understood pieces of the IT technology puzzle. The solutions can be complicated and are always expensive. But when the cost of administrative overhead, compliance issues, and business drivers are added to the technology price tag, the case for IDM becomes compelling. Hopefully the information that we covered here will prompt the reader to ask new questions and look at new solutions for some of the most common enterprise challenges.

[scott.wright]

Nice article.  I'm about to jump into one of the complex environments you've described to develop a strategy for prioritizing centralization projects and identifying major security issues in the process.

It's been a while since this article was posted, but I'd be interested to hear about other folks' case studies on centralizing IDM and Access Management for large organizations, including strategies and pitfalls, how to identify costs, etc. 

- Scott