Introduction to Identity Management - Part II
By David Stern
Before we delve any deeper into IDM, 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” was 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 tie 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 legacy 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.
Posted in Information Protection |
Print this post
|
Permalink |
Comments (1)
• Baltimore/Washington/Northern Virginia (May 10 – May 18)
