More on Directory Evolution
By Mark Wilcox - OVD Product Manager on Mar 23, 2008
This my response James McGovern's questions in his blog. Now if I can just get him to spell my name (Mark) correctly...
Though I do have a question for James before I get to my responses:
"Why does Microsoft get off the hook for not properly addressing standards? Why must a shop who perhaps likes the Windows UI for their desktops be forced to pay Microsoft for AD? Why shouldn't they be able to choose to use another directory server?"
Now for my responses to specific questions.
Question #1 "1. Marc stated: I don't know how often I have to tell people this -
but most Oracle products can connect to AD directly without additional
licensing which begs first a refinement of the question of which Oracle products can connect to AD and ADAM using the LDAP protocol and more importantly since you said most which Oracle products currently cannot?"
Answer #1 - There is only one application that I know that must synchronize user accounts into OID to run and that is Oracle Portal. A few other applications such as E-Business Suite leverage Oracle SSO (OSSO) for authentication and OSSO requires OID. However, even in current version of OSSO - it can leverage OID Server Chaining which lets you keep your username and passwords in AD (or Sun). OID is still required because certain applications like OSSO keep configuration information stored in OID. Though as we have demonstrated with OVD-EUS - we can in certain cases use OVD to emulate OID structure while allowing the data to be stored in AD or Sun if that is what a customer wants to do. However, I should point out many organizations - don't allow you store anything but username and passwords for staff accounts in AD. Thus the opportunity to use OID to store application meta-data while leveraging AD passwords is a very compelling feature.
Question #2 - 2. Marc stated: EUS
does more than just authentication - it also handles mapping of
directory schema to directory users and mapping of directory roles to
LDAP groups but didn't address whether the functionality described should just be a characteristic of any
product that is directory enabled. For example, if Documentum told us
that they support LDAP, should we interpret this to mean that they only
authenticate against it or should this mean that they can also handle
Answer #2 - I don't disagree with that statement. But it does reflect the fact that people tend to confuse authentication vs authorization. Most applications can externalize authentication (e.g. store passwords in LDAP) but most applications still rely upon local rules for authorization instead of allowing external authorization such as leveraging LDAP groups much less new emerging standards like XACML. We at Oracle are attacking this area on several fronts. First - we already support the ability for web-enabled applications to externalize access control to a centralized policy service and the rules management can be delegated to the proper business authority. Second - we are developing a XACML based policy product that will help simplify the development of FGA in applications. The database has supported FGA itself for several years now via virtual private databases. Third - with the integration of Oracle Roles Manager with Oracle Identity Manager- it allows customers to define how their core business roles (which is normally very few such as "Product Manager") into actual IT application level rights (which can be hundreds if not thousands depending upon the number of applications in an organization). Forrester recently recognized Oracle as being the clear leader in moving application centric identity forward.
Question #3 - 3. Marc stated: 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 :) and described how a
product could be a potential solution but didn't talk about any type of
outreach to either these same global 1 billion companies nor the
software vendors that haven't had the sense to buy the most wonderful
books written by you. What is Oracle's obligation to help others write LDAP enabled software so that they don't require virtualization.
Answer #3 - This is an area I think everyone knows is a pain-point. And we are working hard to address this in three specific ways. In short-term we are working on a kind of best practices guide aimed initially at internal Oracle teams but we should be able to share it with the world. Second, in Fusion Middleware 11g there will be a UserRole API which will help abstract much of the LDAP internals to a developer (though this will only be available to Java & related languages like JRuby/Groovy). Then longer term is the Identity Attributes API we are helping to define in the Identity Governances Framework. The concept of the API is my key contribution to that process (though Phil Hunt & Prateek Mishra are much more active on the standards front, while I'm focused much more on productizing support for what the standards process churns out). My belief is that a big reason why developer's tend to go sticking identity stuff in a database is they have access to toolsets that make it very easy to do so and no expectation that identity can be service enabled. So the Identity Attributes API is an attempt to make identity information as easy to use as the database option for a developer while making it simple to hook into the "identity service" when you deploy on the enterprise.
Question #4 - 4. Can we agree that consolidation is a better enterprise strategy than virtualization?
Answer #4 - Virtualization provides opportunity for consolidation. If consolidation was the best strategy on it's own - meta-directories would have become dominant players but consolidation without virtualization does not provide enough flexibility. My colleague Nishant Kaushik recent post gives a very detailed reason why the two go hand in hand.