Don't Band-Aid Your Identity Infrastructure
By Clayton on Apr 01, 2008
My 3-year old daughter is a big fan of band-aids. The band-aid in the picture is a particular favorite. For every real or perceived injury, a band-aid heals all.
Having delivered virtual directory software for quite some time, I've been asked to help deal with a lot of infrastructure wounds. Some of these are real issues that virtual directories can play a strategic role in solving. Others have been areas that are better suited for other identity management technology.
In these later cases, a virtual directory would have been a band-aid on a very serious problem, or maybe a band-aid on a problem that never existed in the first place.
My Favorite: My data sources are flakey.
This can be a real infrastructure issue, but it's rarely something a virtual directory is going to solve.
Why? Because you want your identity information fresh and secure. The virtual directory way of solving this problem would be with a cache. However, caches have several draw-backs:
- They get old. Identity information needs to be fresh. Do you really want accounts hanging around for hours after someone has been escorted out of the building by security? Some vendors try to solve this by keeping remote repositories in sync, but this just opens up the virtualization layer to all of the problems of meta-directory.
- They bypass security at the source. By using a cache, you are keeping a copy of the data in the virtual directory that will be shared by all users instead of understanding that different people may have different data available to them.
- They're difficult to manage. A cache adds to the total cost of ownership of your infrastructure. After all, you'll need to back it up, secure it, replicate it, distribute it, and otherwise think about it a lot. By keeping the virtualization layer simpler, it can often sit in a closet without much attention at all.
What are the Alternatives?
In many cases, no alternative is really needed. That band-aid may have added some psychological comfort, but it wasn't what healed the bruise.
How badly does your data source really perform? Why is that performance acceptable today? Do you have a better place to get that information?
I hear the concern about network links a lot, but in these cases the concern often doesn't reflect the fact that if a link is down, people often lose access to the applications using the identity as well.
Often there is a bit of cover-your-rear here, and vendors can play a part. It's a bit like taking your car in for service and hearing "your breaks may be okay, but maybe you should replace them before you get into an accident". You're less likely to question the source of the advice if it sounds like they're keeping you safe.
However, you may in fact have real issues with your data sources.
In these cases, the answer is almost invariably that it's cheaper and better to fix the source. It's much easier to add an extra directory replica or replicate your database than it is to have a long-term solution that involves a product being successfully able to detect changes in all of your infrastructure components.
In cases where this data needs to move around, provisioning is a mature technology with a lot of success in solving exactly this problem.