To quote the Scarecrow from the Wizard of Oz, "There are pieces of me here. There are pieces of me there."

Thanks to years of independent evolution, user identity information also exists with bits and pieces in different places. This presents a challenge to application developers responsible for writing software that needs to take into account potential access from people across the enterprise who may be in any number of separate identity sources. It also presents a security challenge as allowing access to one application may open doors to others that are best kept shut.

Metadirectories like IBM's Directory Integrator (IDI) and Microsoft's Identity Information Server (MIIS) solve some identity problems by consolidating data from these multiple repositories into a new repository that contains the full picture. Consolidation is important because it reduces the management effort to maintain and improve the quality of attributes that exists for the same individuals across multiple enterprise data sources. Consolidation through the use of a metadirectory can be extremely powerful, but as those who have walked the yellow brick road to metadirectory know, consolidation brings new challenges.

One is data latency. Because they're drawing from other sources, metadirectories need to receive updates from the source directories on a regular basis. Often some of that data can be very old when dealing with batch export jobs that run at night. In some cases that may be acceptable. But what if you're looking at access rights to the network? A terminated employee may have his/her identity removed from the source databases. If it's left in the metadirectory until the batch run, however, that employee could have access to the network the entire day. That's a huge security risk, especially if the employee was terminated suddenly or under very negative circumstances.

Another concern is data ownership. Many large organizations use Web services to create portals for suppliers or employees. Those portals may pull data from a variety of sources. Suppose a portion of the data comes from HR, giving employees the ability to check on their 401(k), number of vacation days left, health benefits, and so on. If it's sitting in a metadirectory controlled by IT, the HR department loses a portion of its control over the data, and the organization is vulnerable to potential liabilities. Should a problem arise, such as confidential information about salary structures leaking out, it could spell disaster and/or lawsuits.

Another example would be regulated industries such as health care service providers, where a given user may be both an employee and a subscriber to the benefits. Both populations could have access to the same application(s); however, strict guidelines or laws mandate that subscriber data is contained in separate physical data stores.

Rather than being the wizard behind the curtain, virtual directories work to present data to applications directly. They are designed as middleware that takes requests using standard protocols like LDAP. They then rewrite and route the request in real time to one or more directories, databases, or other sources that contains the information necessary to fulfill the request. Once the operation is fulfilled, they simply dissolve like the Wicked Witch of the West when the water is thrown on her.

As middleware, rather than behind-the-scenes infrastructure, virtual directories eliminate the need to synchronize identity information to a central place. The application always works with the most current information because it's drawing from the source directory and not a copy of the information. Eliminating the need for replication and hard storage also assures that the data remains under the control of the original owners and that it complies with regulations that ensure data privacy. In the previous example, when the employee accesses the HR portal, the data is drawn and presented to that employee. When the employee is finished, the access point is closed and the data is again protected by HR until the next authorized query.

Another advantage is that virtual directories have the ability to present the same source information differently to different applications in much the same way that a database administrator can create multiple views of the same database tables. As a result, drawing and routing the information for new applications is greatly simplified. Finally, rather than a nine-month infrastructure project that could delay production rollout of portals and other key applications, virtual directories tend to have deployment cycles measured in days due to their non-invasive nature.

While fast, non-invasive deployment is usually great, there are places where metadirectories are still the right choice. For example, they are great for keeping key infrastructures such as NOS and e-mail in synch. These are special-purpose enterprise directories that need to be kept up-to-date with their own proprietary and application-specific data. The key is to determine the requirements of the job and its limitations, and then select the directory option that best fits the parameters.

The fractured nature of user identity information is a fact of life. Yet it doesn't have to be a barrier to accomplishing what needs to be done in the enterprise. Virtual directories provide Web services developers with the ability to take all the individual pieces of straw and rebuild the Scarecrow in new, more interesting, and more secure ways - all while speeding the development cycle. That alone makes them worth a look.