Wednesday, April 16, 2008

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)

 


Monday, April 7, 2008

"Oh, I see now. Virtual *IS* Meta!"

Got to love this posting by Phil Hunt.  I've been watching this bit of diatribe back and forth, especially between Dave Kearns and Kim Cameron.  It's a bit like the old story about six blind men trying to describe what an elephant is, each only feeling one part of the beast. One says "it is like a wall", another "it is like a tree", and so forth. 

SO, are we really talking about multiple problems, or one problem with several aspects?  do we need multiple solutions, or is one elephant enough? 

This discussion is good, and I hope everyone is reading all the posts.  They are essential arguments and these guys are no dummies.

Jackon Shaw << Jackson started it here!! / blog home page
Dave Kearns
Kim Cameron
Phil Hunt
Felix Gaehtgens

if I missed someone, let me know... oh yeah... I put in my two-cents here. :)

Wednesday, April 2, 2008

Worst practices: Exposing IAM blunders

Joel Dubin exposes the most common IAM blunders, and enlightens information security professionals on how to prevent these mistakes. OK, its a bit basic, but they are still problems. I thought the article was uninteresting, but two things caught my attention:

1) multiple logins for multiple applications (listed as the sticky note syndrom)

2) "ghost" passwords - which are more precisely "ghost" accounts, not just passwords, they are logins that should not exist.

If you are correlating any and all identity profiles in your enterprise, then these orphaned accounts can be properly detected AND accounts could be linked to aggregate same-user profiles from the various applications, enabling true SSO. No more multiple logins, no more "ghost" or rogue accounts. 

Utilize an abstraction layer to virtualize sources together, correlate identities, and provide provisioning for identity lifecycle management. Delivering identity data from a central virtualized source can solve this problem.  If your environment is a dynamic and ever changing business (and who's isn't these days) then this is the only way to go. 

read more | digg story