As most of you know, I try to keep up on some blogs out there, one of which is Jackson Shaw's. I wanted to throw in my two cents on a couple responses he made yesterday to another blog's posting (James McGovern).
JAMES: If pretty much every Fortune 500 enterprise (acknowledging that Sun is the standout oddball) has Active Directory, why should any of them consider yet another product? Why shouldn't they simply wait for Microsoft to include virtualization support in Active Directory? Please no responses that are "tactical" in nature nor attacking Microsoft because they never get it right the first time.
JACKSON: I agree. Why should they? It's obvious - at least to me and I am pretty sure a lot of other folks out there - that identity management has evolved beyond directory synchronization and metadirectory to include the concept of virtual directories and all of what that means. Is there ever an ideal product? Sure, for a period in time. But times change. If Microsoft isn't thinking about how to solve this problem I would be surprised - oh, and let's not forget that a possible solution is to do nothing.
Yes, Microsoft already has several options to managing the problems solved by virtual directories, if you are a primarily Microsoft shop (if someone really wants to know, let me know and I will get you a list).
They (Microsoft) are interesting in selling more products, and keeping you "in the fold", virtual directories tend to give you more freedom to leave the sheep pen. If you are a Microsoft shop, then their products integrate relatively well with their other products. I'm not as magnanimous in my feelings that Microsoft is particularly interested in the problems that are primarily encountered in a non-Microsoft centered architecture as Jackson.
Also, this idea of using AD for a central identity store, umm not so fast. There are a couple issues, yes almost every enterprise had AD, but that doesn't mean it is their central identity store. (1) AD stores lots of information, primarily related to its original design of being a NOC directory. Moving all your needed identity information into AD is just a bad idea in the minds of a lot of architects who don't want to "tinker" with AD operations. I would agree with their position here. (2) Also, it is not offer high enough performance for many deployments, so then you replicate instances, and things get more complex. Say a SunOne Directory Server is performing 5K-6K quires per second (qps) on the same hardware you could see AD performing only 2K-3K qps or less. I've seen AD doing less than 900qps. (3) Then you have the issues of non-standard LDAP operations, there is a rather long list of things I have compiled over the past year that AD is just not LDAP v3 compliant with, not the least of which is most applications want to see "inetOrgPerson" objectclass, not "user". These little things can hang up projects for longer than you might think. Yes, again Microsoft has "work-arounds" but if you aren't committed to being a Microsoft customer no matter what, why would you try to go this route?
JAMES: The ideal situation says that a software company should be able to write an directory enabled application without requiring virtual directories but reality is a little different. Wouldn't the thought leaders in this space without resorting to tactical responses agree that instead of pushing products/tools in this space we have to help others understand the <> so that this problem goes away? Even products by companies with really smart individuals such as EMC still get this wrong. Does Oracle have any thoughts on helping people avoid virtual directory by writing better directory-enabled applications or is it better to bury one's head in the sand, ignore the problem of others and simply respond with point solutions.
JACKSON: James, you are right. Software companies need to do a better job when they write directory enabled applications but it is a long road. The average application developer still needs to do a better job managing identity, authentication and authorization.We still have a long way to go unfortunately.
Sure, in the ideal world... well maybe... This exchange of ideas makes more sense if virtual directories is only viewed as an LDAP proxy, a way to aggregate multiple directories, centralizing data sources. They do more than that, they
- integrate applications, databases, web services, and directories,
- disambiguate same-user accounts to integrate identity information (even establish previously non-existing key mapping),
- overcome performance issues of underlying sources,
- "push" information for provisioning
- use an ESB for messaging / synchronization,
- data model new views of data,
and the list goes on-- you face one or more of these things with each new deployment.
I prefer the idea of having a central access point for identity, and just creating a new view based on my new requirements rather than configuring applications over and over, duplicating my efforts. I do the work once and my applications have one place to look for the information (for authz and authn). It saves A LOT of time. Even if you do have an application that supports directory services very well such as CA's SiteMinder (which offers a lot of functionality to connect multiple sources), but still you configure all this and it is only consumed by SiteMinder. I've lost all the effort I've put into this when I have another deployment that needs to consume the same or similar identity profiles. There really is a lot of duplication of work here for different applications.
Which is quicker? Configuring each application's virtual-directory-like component, or just creating a new view in a virtual directory to be consumed by a new application?
I would be interested to hear with others think....
Posts
No comments:
Post a Comment