Virtual Identity Dialogue

Wachovia has recently chosen Oracle Directory Services to improve their enterprise directory services.

And they recently recorded a video explaining why they made this decision.

One of the hidden benefits of coming into Oracle was that we have been able to leverage Oracle support. The directory services support team - which is over 30 people world-wide is comprised mainly of people who have been supporting OID and LDAP for several years (some close to a decade). Our support team alone is almost larger than our competition's entire company. This doesn't even count the related teams like stress and performance teams plus of course our core development team.

Additionally - Oracle support means the ability to leverage Metalink. Metalink is Oracle support's knowledge base. We have now recently completed a major project of publishing internal support notes that I had been maintaining to Metalink.

While it does require a valid Oracle support license to access Metalink - the result is that anyone - customers, sales and partners now have access to a wealth of a additional material that we have collected over the years.

Jackson Shaw recently wrote "The Meta-directory is Dead".  This post seems to be sparked by HP's announcement that they are leaving the identity management business.

However, saying "meta-directories are dead" isn't news to anyone paying attention. The concept of a meta-directory is that you can copy all of your identity information into a single repository to be used by all applications. However, that isn't practically possible - it takes too much time, it's too inflexible and you always run into regulations or internal politics that work to prevent it completely or delay it for years.

What hasn't changed is that the problem that the meta-directory was trying to solve hasn't really gone away.

The fact remains is that for good or bad - LDAP is still the easiest protocol to integrate with for authentication and authorization - in particular for off the shelf applications. And all of the new(er) standards like SAML, Liberty and XACML all build off LDAP directories.

But the trick is that the identity information is often contained in something else and you must be able to bring it together dynamically. That of course is where a virtual directory like Oracle Virtual Directory comes in. And because the source data stays in its existing repositories - it's much quicker and easier to deploy.

Additionally more and more organizations are finding themselves in the situation where they need to store the identity information for customers, partners or vendors as they continue to move more and more business on-line. Or perhaps they already are on-line but because they are integrating with new systems like mobile phones - they need to store additional context about that account.

Thus you may find needing to manage very large amounts of directory data - that Oracle Internet Directory can do very easily on less hard-ware than competing solutions.

Plus we're working hard on achieving that identity "dial-tone" Jackson mentions. In terms of reliability and performance - we are already there but with 11g we will raise that up another notch.

In particular I think we are making significant improvements in further simplifying configuration and operational management of directory services.

Finally Web Services is definitely a hot topic around these parts and it's something we are investing in as well which I will share more about in the future.

In summary:
* Everyone benefits from having a single point of contact for identity information
* Virtualization of the identity information simplifies the deployment of that single point of contact and improves on the investment of existing systems
* Most organizations will see an increase in the need of manageable, scalable, secure directory storage

My post on Evolution of Directory Services sparked something from James McGovern.

To quote:
first:
"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.











 

Nothing identity related - but technology related.

In past week - I have watched two major news stories - Spitzer's call-girl scandal and now Obama dealing with alleged racial comments from his former pastor.

Basically these are traditional news stories but both were augmented by Web 2.0 as sources. The first pictures of Spitzer's "friend" - were from MySpace. And last night CNN was airing footage of Obama's pastor - from YouTube.

I just find it fascinating how rapidly new ways of communicating are integrating into the mainstream.

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
mapping?

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.

I don't quite remember how I found this blog link but it's a good introduction to all of the components that make up Oracle SOA and help get you started.

And if you are doing anything with Web Services - make sure you have SOAPUI in your toolkit. There isn't a faster way that I know of to test out the services.