There's More to Enterprise Identity Than Validating AD Passwords
By Mark Wilcox - CTO - Oracle Consulting Security-Oracle on Mar 17, 2008
My post on Evolution of Directory Services sparked something from James McGovern.
"talks about virtual directories but doesn't talk about how Oracle products should be able to bind to Active Directory without additional licensing" .
I don't know how often I have to tell people this - but most Oracle products can connect to AD directly without additional licensing. I believe people continue to confuse EUS (which is a database security option that happens to leverage directory services) with every other Oracle product. EUS does more than just authentication - it also handles mapping of directory schema to directory users and mapping of directory roles to LDAP groups.
And another quote:
"I guess Oracle doesn't acknowledge that 499 of the Fortune 500 run
Active Directory. Sometimes the best answer is less products, not more!"
Again - nobody debates this fact. But it doesn't mean that binding directly to AD alone provides enough of a solution or is even necessarily a good enterprise architecture because it doesn't easily accommodate flexibility.
And all of the Fortune 500 and pretty much every one of the Global 1 Billion companies have additional user identity stores not stored in AD or even an LDAP server for that matter :). This again is an area where virtual directories are uniquely positioned to assist with because we can make everything appear consistent and homogeneous even when the back-end identity stores are anything but.
Finally consider these statements:
1 - Most organizations have multiple AD domains and most LDAP enabled applications don't deal with that use case very easily
2 - Tomorrow your organization could re-org or be merged or acquire someone. This will result in significant changes in your enterprise identity systems.
3 - It is unlikely - in particular as people move further and further into fine grained access control - that all of the attributes necessary to make those decisions - are contained in a single system.
What virtual directories provide is a low-footprint abstraction service between applications and their identity sources so that if any of the options 1 through 3 occur - the changes to the application are minimal.
It also means if you are an ISV and wanting to simplify your life in developing directory enabled applications - you might seriously want to consider looking at having a virtual directory integrated with your product in some fashion.
In most organizations - AD is simply just a password server - that happens to speak LDAP (and Kerberos and RADIUS) plus some additional bits to help manage Windows networks. There is nothing particularly wrong with this approach - except when you start to integrate other enterprise software into the mix. Sometimes you need additional data to be stored with the person's entry or you need to use an attribute that is present in another source like the HR database. In these instances - you need something else to help and that is what a virtual directory can provide very easy and with a small footprint because it is usually leveraging existing data & systems.
For example - imagine the scenario where you have username and passwords in AD but organizational role status and related attributes are maintained in your HR database. If these rules don't apply to anything needed to access in Windows - you don't have any real reason to synchronize them to AD (assuming they can even be mapped to AD schema).
But OVD can provide a single on-demand view of the data from both AD and your HR system. Thus users get to authenticate using their Windows passwords but access control is driven off attributes in HR system in real-time without needing to do any other synchronization.