ABAC + RBAC = ARRRRR-BAC
Wednesday, October 28th, 2009
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.
