Live and let Live

It is time to put my two cents to the ongoing dialogue revolving around RBAC versus ABAC.

My impression is that talking RBAC down is presently in fashion and used as a pretext to promote ABAC.

The pro-ABAC Advertisement Campaign foresees an impressive list of reasons. The most popular among them are:

• RBAC projects start with high expectations
• The real world just happens to be too complex to model efficiently with RBAC.
• RBAC misses the context
• RBAC is very costly
• RBAC is almost impossible to finalise
• RBAC is Static
• RBAC leads to Role explosion
• RBAC (Roles) are not interoperable

But the “gem” is

• The RBAC model as opposed to the ABAC model is not context-aware and is thus not well suited to handle SoD requirements.

As a kindness they allow roles to be used in ABAC, as one of the multiple attributes that ABAC can engulf or use to make access decisions.

Now: I can logically agree on all the syllogisms that are used to justify the prevalence of ABAC, but the problem is in the starting axioms: what enterprise authorization solution is actually using “pure” RBAC as a determining factor on whether to grant access to an asset or not?

For instance, our solution IDEAS Enterprise Entitlement Server (the new name of our Enterprise Authorization Server) provides an entitlement model that unifies role-based, rule-based and attribute-based access control.
With this model, entitlements may include dynamic authorization information, such as: contextual attributes (e.g. time of day, value of a transaction, a physical location, ..), user resource attributes (e.g. an account, an organization, ...), and rule-based business logic (e.g. exceptions, call-outs, …).
Of course, historically, we our roots are in Role Management, thus roles have a central position in our solution, but in order to map any application authorization framework, we have included Application mapping capability from the beginning, in our unique data model, that allows for flexible definition and evaluation of complex access control policy sets.

So, instead of only using roles as the determining factor on whether to grant access or not, many attributes can be used. The hybrid adoption of RBAC together with additional context simplifies the making of access control decisions (at finer levels), allows easy compliance with regulations, and very importantly, minimizes governance problems.

Here is an example of authorization policy mapping using IDEAS.

The application is a fiction stock trading application, used by traders in a bank to buy and sell stocks on various stock exchanges.

First of all the model has an:

Actor: the subject (e.g. user that can be mediated by roles, ...) for whom the authorization is evaluated. Example Mr. X with the “Senior Bank Operator” role

and it is based on four entities:

Permission: is an action on the Resource (also called Operation). Example: Trading.

Resource: is the Application element to protect. Example: Stocks.

Constraints: are the Conditions that must be validated to grant the authorization. Two or more Constraints can be merged with a boolean combination of their values. Examples: Trading depends upon the user geographical area; Transfer limit is based on user characteristics; SoD conflict verification in real time.

Exceptions: are other conditions that can further limit the authorization decision and that allow for the creation/evaluation of more complex business logic. Example: Trading not allowed for companies where the user is involved.

that rely on a Role Management infrastructure.

Very lean and straightforward!

I just want to put in a good word now and refute the statements that have been made on Role explosion and SoD management. Once again it is just a matter of selecting the right tools and adopting the appropriate methodology.

In the next post I will try to describe a framework that is able to, not only stop this overstated issue, but above all allow stepped construction of sound and governable role infrastructure. As a matter of fact, it is mainly a matter of using the right tools!

For me, however, the most surprising argument that was raised against RBAC, was SoD management. SoD, and in general, easy compliance is one of the strongest points of adopting Roles in an Access governance framework.
For example, IDEAS offers the possibility to easily define and maintain the scope of roles based on the organization unit structure (for implementing need-to-know, need-to-share). Further, the proposed SoD model allows business users (that might have no knowledge of IT systems) to define potential conflicts among business activities (e.g. “purchase order - creation” or “purchase order approval”) rather than among entitlements, thus decoupling business and IT aspects as well as leveraging a business perspective.

In my opinion (sorry if I now use comparative reasoning) the policy administration issue should not be underestimated. I’m sure that by using IDEAS even a very complex authorization policy is far more viable, thanks to adopted data structuring.
On the other hand, how can XACML policy be set and analyzed? What kind of tools are actually available for managing a very complex application authorization policy with multi-valued requests and rules? What about conflict verification checks?


To wrap-up, I don’t think we need RBAC and ABAC slinging mud at each other (like a typical Coke and Pepsi duel). We don't want to create bad karma: we need to support BOTH! (many agree with this).

Sit down and decipher the most advantageous benefits of your company and its products, without bashing others; because other approaches are also on the horizon… like Risk Adaptive Access Control (RADAC).

It could be a never ending quarrel…

And once again…

Live and let Live