Oracle and Sun RBAC Acquisitions
Updated below. And as a reminder, this is my personal blog, and I don’t pretend to represent the views of my employer, Novell.
With Oracle acquiring Bridgestream and now Sun acquiring Vaau, I know all of you are asking yourselves “I wonder what Bob thinks about this?”.
No? Well, I’m going to tell you anyway.
Novell decided earlier this year to develop our own roles module, which you might think killed any chances of us partnering with third party RBAC vendors, but not so. Just last month we conducted a joint project with Eurekify, a relationship that both sides are looking to expand. So why would we develop a roles module in-house instead of acquiring an existing vendor? And once down this path, why still partner with Eurekify?
There are two distinct pieces to RBAC software. First is the software that computes user privileges based on roles and provisions them. This functionality requires a very specialized database that is highly tuned for performance in a rather narrow set of tasks dealing with identities and entitlements. We call this specialized database a directory, and Novell happens to have one. For role-based provisioning to work effectively, it needs to be built on a directory. Acquiring a third party product and integrating it into an existing directory requires a massive re-write. So we didn’t do it. (Actually we did acquire some third party RBAC software that was already built on top of eDirectory, and have been enhancing from there.)
The second piece of RBAC software is the roles mining and analysis that supports the development of optimal role definitions. This functionality requires a lot of ad hoc queries and computations based on matching many different pieces of data. This workload has a very different profile from the straight role-based provisioning, and requires the flexibility of a relational database.
Vaau, Bridgestream and Novell’s roles module all support the first category. Vaau and Bridgestream are trying to also compete in this second category, but they are playing catch-up. The clear leader in role mining and analysis is Eurekify.
Vaau and Bridgestream are trying to be all things to all people, but they will face the challenge of, on the one hand, integrating with Sun’s/Oracle’s directories to support role-based provisioning, and on the other hand, trying to expand the analytical capabilities that can only be built on top of a relational database. They’ll be busy for awhile.
Meanwhile, Novell is not trying to pretend we compete in the role mining and analysis space. We are providing a highly tuned role-based provisioning capability based on eDirectory, and we will partner with Eurekify for the things a directory, and a directory company, can’t do well.
(Now, to kill any rumors, I know of no acquisition talks with Eurekify, or the lack thereof. I’m not being coy. I truly have absolutely no information that is not already in the public domain. Actually, I have less, since I’m sure there’s a lot that is public that I haven’t seen.)
So the Bridgestream and Vaau acquisitions are somewhat of a “me-too” strategy, matching Novell’s direction of integrating role-based provisioning into our IdM suite. But the acquisitions carry significant added challenges as well. And they preempt Oracle’s and Sun’s ability to partner with Eurekify for role mining and analysis, which given Eurekify’s leadership in this space, they may come to regret.
Update: Novell has announced our roles module, named the Roles Based Provisioning Module.
Let me start out by saying that I prefer directories to databases for the storage of entitlements (roles) for a user for applications.
You wrote:
=====
This functionality requires a very specialized database that is highly tuned for performance in a rather narrow set of tasks dealing with identities and entitlements. We call this specialized database a directory,
=====
There are times where a directory will not (easily) provide the necessary relationships that can be provided by a database. Specifically I am thinking about scopes at the Role level. Can you give an example how you would provide scope at the role level using a directory?
Here is my definition of scope.
CreateInvoice and ApproveInvoice are the the roles for an application
a user can be assigned one to many of 200 offices that they can CreateInvoices for and the Approve Invoice offices can be different then the CreateInvoice offices. So the scopes for each role can be different. I would be interested in a solution using a directory.