Starting Point for Identity Services

A while ago, I posted about the Identity Management Continuum. I want to revisit that topic from another angle. As we move toward a service-orientation and establish a more component-ized architecture approach, it becomes easier to insert, remove or swap any one particular piece of the puzzle. The continuum still exists - an Identity Services infrastructure is dynamic, should be implemented in phases and should be cyclically re-examined in accordance with business goals. But the starting point clearly varies based on the needs of the organization. For some companies, a particular set of functionality is important. They want to reduce the number of user passwords, provide self-service password recovery, provide a single sign-on service or user-enable a new application. For other companies, the goal is simply to start building an identity infrastructure. Either way, the solution design goals are the same - to implement an open and flexible identity services infrastructure so that components can be added, improved or removed as business needs change.

One solution that makes this architectural approach extremely accessible is an identity services data abstraction layer. An abstraction layer unties the bind between identity services and identity data. Identity data is typically stored in multiple locations, structures and formats throughout an organization. Mapping each identity service to all of those data repositories is a daunting effort. One way of building an abstract layer is by creating an enterprise directory that holds all of the organization's identity information. This can be effective if an organization knows all of the identity and application requirements for this uber-repository. Unfortunately, application requirements change. And data repositories change. And new services rise and fall. Due to the dynamic nature of the business environment, enterprise directories are difficult to manage and maintain. There's often a trade-off between enabling new services and just keeping up with status quo.

An alternative approach is to leverage virtual directory technology as a data abstract layer. Virtual directory technology not only effectively maps identity services to identity data to meet current requirements, it also enables the organization to rapidly adapt to changing business needs. Migrating data repositories to new formats or structures is a seamless experience for the consuming applications and services. Adding new services is easy because identity data is accessible in a single location via customizable views.

I've often heard people discuss virtual directory technology as cutting edge technology that's only adopted by advanced organizations that have well-developed identity infrastructures. I propose that we (as the IdM community) ought to be encouraging the businesses we serve to look at virtual directory technology in the earliest stages of design. Since our process is cyclical and our requirements are dynamic, it's extremely important to be able to adapt to ever-changing identity needs. Virtual directory is a no-brainer for this scenario. If implemented early enough, organizations can greatly reduce the workload of implementing and managing identity services each step of the way - say by 20% - 25%. Isn't that the portion of the effort associated with integrating identity services and applications with the underlying data?