ABAC + RBAC = ARRRRR-BAC

Arrrr, me mateys!

I'm going to stand on my soap box for a few minutes to share my take on the ongoing dialogue around RBAC versus ABAC. The debate over which one is better seems to be as heated as the debate over which side of a black and white cookie tastes better (Seinfeld - Black & White Cookie Episode).

I'm constantly asked by customers about which approach I prefer. Analysts seem to enjoy this conversation as well. In fact, Kuppinger-Cole did a nice Q&A on the debate earlier this week and does a great job outlining the issues.

Critics of the RBAC model argue that RBAC is static and believe that taking an RBAC-only approach will lead to an excessive number of roles. They argue that policy decisions will need to leverage Roles plus attributes embedded within your application infrastructure.

Honestly, I think the debate here is somewhat self-created by framing it in terms of RBAC versus ABAC rather than simply acknowledging that a good policy engine needs to support both roles and dynamic attributes. It is very rare to come across customers that are able to contain all attributes within a role. I have yet to see a real-world organization with a clean RBAC implementation. Arguing for purely RBAC is a nirvana that casts a blind eye to the grey areas of the application infrastructure world.

The issue of RBAC v. ABAC is less a decision about choosing one over the other and more a decision around where one draws the line when defining roles. Todays organizations need to define a clear line between what attributes should be part of a role and what should remain application specific. The balance between how you define roles versus attributes is very use case driven and contextual to each customers environment. This boundry is often based more on business context, IT budget, perceived value of abstracting identity from apps, and a gazillion other factors that could influence what you should do.

From the perspective of entitlement enforcement, the basic jist is that any system that is going to work for a customer needs to support both ABAC and RBAC. Policy enforcement decisions need to take in to consideration role definitions and sometimes they also need to incorporate dynamic attributes from applications.

As we refine entitlement enforcement in OpenSSO (our Beta was made available in September 2009) we are looking at this from both perspectives and expecting real implementations to require a hybrid solution that is dynamic and can take in to consideration both roles and attributes. Our solution consumes roles, allows applications to push attributes to OpenSSO for policy evaluation, and allows OpenSSO to pull attributes for policy evaluation. In fact, OpenSSO also supports policy referrals or partial policy referrals to help make an "accept" or "deny" decision.

Thus, my solution is to stop arguing about RBAC versus ABAC and change the name to ARRRRRRRRR-BAC (use the best pirate voice you can muster). Thus, like the black and white cookie, we can all live together again in harmony.

Comments:

Hi Daniel,

I am not sure if I understand this correctly. In paragraph 3 you say that the critics saying that we need roles plus other attributes, and then in the next paragraph you say that the debate is self-created and that we simply need roles plus attributes! Isn't that a repetition of the critic that you somehow object?

There is actually no RBAC vs. ABAC as such, but the debate is if we solve some of the issues that a pure-RBAC model can be avoided by extending the model to talk about other attributes than only the roles of users.

It is good that OpenSSO has now entitlement management capabilities.

Regards,

Babak

Posted by Babak Sadighi on October 28, 2009 at 06:01 PM PDT #

Hi Babak. In the 3rd paragraph I'm simply stating what many critics of RBAC say (i.e.--ABAC proponents). In the following paragraph I'm saying that debating "pure" RBAC is silly as you only see it in textbooks. My take is that it's an academic argument because you will rarely, if ever, come across an environment that is purely RBAC. In fact, it's usually the exact opposite problem. An org is trying to get some semblance of roles in place just to get a basic foundation for compliance. If that makes me a proponent of ABAC then so be it, but I don't really think those that are proponents of RBAC really believe that all attributes will be part of a role. Anyway, thanks for the comment.

Posted by Daniel Raskin on October 29, 2009 at 01:18 PM PDT #

"From the perspective of entitlement enforcement, the basic jist is that any system that is going to work for a customer needs to support both ABAC and RBAC. Policy enforcement decisions need to take in to consideration role definitions and sometimes they also need to incorporate dynamic attributes from applications."

Amen.

We cannot assume that all entitlement enforcement decisions can be made based on Roles only.. It's just not reality. There will always be policies that define access based on a particular entitlement and/or context.

Posted by Mat Hamlin on October 30, 2009 at 12:09 AM PDT #

As a FYI:
A variation of ABAC is Expression Based Access Control (http://www.boliven.com/patent/US7653936, http://www.boliven.com/patent/US20050021977 ) which is being used successfully on a site with a 'significant' daily load http://partners.microsoft.com

It uses both attributes and roles to determine privledges with changes being immediately implemented (I believe that temporal constraints may also be supported in it's implementation).

Posted by Ken Lassesen on November 15, 2010 at 04:51 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Read my extraordinary thoughts about the world of identity and access management. As an identity child prodigy, I have much to say about these subjects.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today