The Directory Landscape
While there are several LDAP-enabled directory server products in use, the five most prevalent are Microsoft Active Directory, Novell eDirectory, IBM Tivoli Directory Server, Sun ONE Directory Server (formerly iPlanet
), and OpenLDAP. Each has its strongholds and advocates, and each individual product does a fine job of storing and working with user identity information.
Why not just leave well enough alone and stay with the directory product that's currently in use? There can be any number of reasons to make such a change. For example, perhaps the organization is consolidating technologies and wants to standardize on a single vendor, as is often the case with a migration to Active Directory. Another reason is that the organization wants to move all divisions to a single platform to reduce maintenance costs. It could be that it is installing a new enterprise application, such as a portal, that requires the ability to reach across multiple directories in multiple departments. It could also be the result of a move to standardize the enterprise after a recent merger or acquisition. Security may play a part as well, since the more directory products you have in the enterprise the more resources you need to deploy to assure security. Or, the organization may have decided to share certain information with trading partners over the Internet to reduce costs and/or increase efficiency.
Whatever the reason, the simple fact remains that the applications currently in place will not work with the new directory infrastructure without modifications. Either the applications need to be rewritten to accommodate the new directory serveror developers need to find a way to bridge between the old and the new.
Virtual Directories: Masters of Disguise
Like shape shifters in SciFi, virtual directories let one type of identity management request appear to be another type. They're masters of disguise, giving each side of the equation what it needs without the need for extensive reworking.
|Figure 1. Virtual Directory Request Conversion: The figure shows how the Virtual Directory Engine (VDE) converts an eDirectory request to the sample HR database to an Active Directory request, without requiring any changes to application code.|
For example, in the simple HR database example, suppose the application were designed to be used with eDirectory, but the organization has moved to Active Directory. The request goes out as before. This time, however, it is routed through a virtual directory rather than straight to the directory server. The virtual directory performs the operation shown in Figure 1
The VDE converts the request from an eDirectory schema to that of Active Directory, enabling the request to be processed in the new infrastructure without changing the original application.
After processing the request, when it returns the identity data, the virtual directory once again provides the conversion presenting the Active Directory content as if it originated from Novell eDirectory.
As a result, the application is able to work as it always has, pulling in the data it needs through a simple LDAP-enabled request. Meanwhile, the organization has been able to make a seamless shift in its directory infrastructure with only a minimal interruption in service. And, the development team has avoided a lengthy, expensive trip back in time to re-do work that was already done right the first time.
The previous example showed a one-to-one relationship between the old and new directory servers. But what about large enterprise situations where there may be more than one "old" directory infrastructure? Or cases where migration hasn't been completed, leaving some of the data in the previous directory product while other data has moved to the new?
In these situations, virtual directories make an even more significant contribution. They are well suited to working in heterogeneous environments, seeking out the data wherever it resides and communicating with the directory server in its native LDAP dialect. Virtual directories are able to establish the connection with each type of directory and determine the proper protocol. They then draw the data, consolidate it, and present it in a single view.
In the case of an incomplete data migration, virtual directories help smooth the transition by allowing it to be gradual. Rather than the "all or nothing" approach required in rewriting applications, the ability to work with data wherever it resides, in any type of directory allows the organization to move at its own pace with minimal involvement of application developers.
One of the most significant applications of virtual directory technology for developers comes when connecting an organization's core systems to those of its trading partners. Many organizations are having a tough time simply getting their own internal applications to work together. Now they want those same applications to work with those created by a completely different group of developers? Here again a time machine would be handy, to use in going back to about 1992 and establishing a core set of standards for everyone to follow. But because that's not likely to happen, the next best thing is again to use virtual directory technology to form the bridge between independently created data schema.
When data requests arrive from trading partners, they are sent to the virtual directory, which authenticates the user's information and determines whether that user has the rights to access the data. It then reaches out to the organization's database(s), pulls down the requested information, presents it in a single view, and sends it back to the trading partner's user. No work has to be done by developers to enable access to those authorized databases; the virtual directory allows each side to see the data as they require it.
As a bonus, the virtual directory not only acts as the universal translator but also as an LDAP firewall to prevent outside users from having direct access to an organization's proprietary information. Internal data is made accessible according to the organization's business rules while remaining secure.
No Looking Back
The one overriding lesson about time travel in science fiction is that you can't change history. With virtual directories, there's no need to change it. They allow you to keep moving forward with new development projects while taking care of the infrastructure group's need to tinker with their own technologies. Knowing about virtual directories can keep you from having to go back to the future on all your old projects.