LDAP Directory Proliferation

Matt Flynn posted "Proliferation of Multiple LDAPs" today.  Matt's post was fueled by the recent meta vs virtual debate, which is a nice segway to talking about how to deal with the increasing number of identity stores within the enterprise. 

He suggests examining your current environment, paying attention to these factors:

• Which data stores have overlapping data and which are unique?
• Does it make sense to consolidate?
• Is the data mappable across systems? Do they share unique identifiers?
• Where can multiple applications share a single store?
• Where do given applications require access to data in multiple stores?
• What applications or uses are coming in the future?
• Which stores are used for critical apps? What is the up time demand?
• In what format is the data stored?

His article focuses on directories, increasingly common to read referred to as "LDAP stores". Certainly, identity stores revolve around these hierarcal databases, why?  Because of the reliability, performance, and implicit context provided which is a perfect match for security and IAM solutions.

Just some food for thought.  What if you have an application that could make valuable use of information stored in a relational database, a web service, or specialized application?  What now? These types of data stores are proliferating at a higher rate in the enterprise than LDAP directories for sure.   You could...

1. ignore the possibility of using the data and recreate it (ostrich approach)
2. replicate the data into an LDAP store (creating potentially complex synchronization requirements and introducing data that is at some level, out of date with the authoritative source)
3. use the non-ldap source directly (which will probably not be as secure, have the availability, or provide an overall solution for most IAM packages)
4. use an LDAP proxy to access the information (which will still have the performance problems since a proxy can not perform faster than the underlying data source)

What to do??? By the time you got to my 4th point, you probably were ready to take option #1, admit it... 

Metadirectories are just too expensive, take too long to deploy, difficult to adapt to new sources and/or new synchronization requirements, and the list goes on. People use metadirectories as the "end-all, ubber directory", only to realize the multitude of new requirements not addressed within a year of deployment.  Most virtual directories are too light-weight, offering little more than an LDAP proxy solution. 

Here is my short list of what a solution needs to offer, regardless of your environment.  You needs will change, so your solution should be adaptive and offer more options than you will use today...

• flexible data representation: able to compose identity objects on proxy or data model views from disparate sources (such as data virtualization platforms offer)
• performant: yes, I know its not "really" an English word, BUT IT SHOULD BE, we need this word :)  you need to have the reliabilities, availability and overall performance that LDAP compliant directories offer
• caching options: this includes cache refresh options (i.e. event-driven, TTL, local/distributed, etc)
• synchronization: at the object and even the attribute level, keep it light-weight, and the option of real-time updates OR not - the choice is the key
• identity mapping: identities need to be correlated across the data stores, regardless of the data store type and maintained automatically (it is important to have the ability to subsume new sources quickly and effeciently)