Introduction

Recently, at a customer’s site, I heard an enlightening response to a simple and straightforward question.

The question was: “Why do we implement our access management system according to the old fashioned RBAC model and don’t follow the modern ABAC approach instead?”

The answer came quickly and was as simple: “As we are a large organisation, to go for ABAC would be a step too big for the start. So first let’s implement according to RBAC and later we go on to the ABAC model.”

Figure 1: The (perceived) Evolution of Access control

The answer left me wondering whether there is a logical sequence in which to implement an access model according to the ABAC approach: first RBAC then followed by ABAC? Indeed, while researching literature I found some proposed or perceived evolution paths, like the one illustrated in the graphic above (e.g. here:, also conveying the promising news that XCML support all of these models) here .

However, why couldn’t it be the other way round? Or can’t we have both at the same time, as roles are a good idea. But the dynamic access control, which often comes in the wake of attributes, might be very beneficial as well. What’s about a blended model, having the best of both worlds?

What is RBAC?

Role based access control (RBAC), as defined in the US standard ANSI/INCITS 359-2004, Information Technology, controls all access through roles assigned to users. Each role assigns a collection of permissions to users.

Herby RBAC assumes that, in most applications, permissions needed for an organization’s roles change slowly over time, but users may enter, leave, and change their roles rapidly. RBAC meanwhile is a mature and widely used model for controlling access to corporate information.
To cope with its early limitations, inheritance mechanisms have been introduced, allowing roles to be structured hierarchically. So some roles may inherit permissions from others.

Intuitively roles are understood as functions - or bundles thereof - to be performed within a corporation. Not surprisingly they offer a natural approach to express segregation-of-duty requirements, where no single individual may be assigned all functions for critical operations such as expenditure of funds.

It is evident, that roles are global to a given context by their very nature. Proper operation of RBAC hence requires that roles fall under a single administrative domain or have a consistent definition across multiple domains. In contrast employing distributed role definitions may become challenging.

But not all permission determining dimensions are functional. What is about location, legal entity, customer group, cost centre and the like? Those ‘attributes’ in conjunction with the job function span a multidimensional vector space. A Point in this space defines the package of permissions.

Figure 2: A simple (static) role meta model

The separation of functions & constraints pays off even without complex rules

In the (simplest) role meta model …
Roles express the function
Parameters are used as constraints
They combine to several business roles
Business roles are defined in pure business terms
Business roles must be mapped to entitlements.
Entitlements are operations on objects
Business roles may be statically generated.
They may be determined dynamically at run time.

Of course, if the only tool, you have at hand is a hammer, all the world may look to you as a nail – or a variety of them. And so the inevitable happened and roles, with their functional nature, were abused for the assignment of any bundle of permissions, quickly leading to the well-known role explosion.

Also the static nature of roles is increasingly felt as a severe limitation - in some cases. Where does agility enter the game? Well the context is to blame – and requires dynamic constraints. To make this cryptic statement a bit clearer, let’s take some examples …

Device
The device in use might limit, what someone is allowed to do.
Some devices like tablets or smartphones might be considered to be less secure than others.
Location
The location the identity is at, when performing an action. Mobile, remote use might be considered less secure than access from within the headquarters.
System health status
The current status of a system based on security scans, update status, and other “health” information, reflecting the attack surface and risk.
Authentication strength
The strength, reliability, trustworthiness of authentications. You might require a certain level of authentication strength to apply. Otherwise you might want to restrict access in a certain way.
Mandatory absence
Traders may not be allowed to trade in their vacation. Mandatory time Away (MTA) is commonly used as a detective / preventive control for sensitive business tasks.
Many more …

It is evident, that static role models cope badly with such dynamic requirements.

What is ABAC?

To avoid “role explosions” and to provide for a higher agility, several attempts have been made. Likewise recent interest in attribute-based access control (ABAC) suggests that attributes and rules could either replace RBAC or make it more simple and flexible.

The attribute-based access control (ABAC) model to date is not rigorously a defined approach. Its central idea expresses that access can be determined based on various attributes presented by a subject. These contemplations can be traced back to A.H. Karp, H. Haury, and M.H. Davis, “From ABAC to ZBAC: the Evolution of Access Control Models,” tech. reportHPL-2009-30, HP Labs, 21 Feb. 2009).

Hereby rules specify conditions under which access is granted or denied.

For example ...

A bank might allow access if the subject is a teller, working during the hours from 7:30 am to 5:00 pm, or the subject is a supervisor or auditor working those same hours who also has management authorization.
This approach at first sight appears more flexible than RBAC because it does not require separate roles for relevant sets of subject attributes, and rules can be implemented quickly to accommodate changing needs. The trade-off for this flexibility is the complexity introduced by the high number of cases that must be considered.

Providing attributes from various disparate sources adds an additional task. Attributes may stem from different sources with different reliability resulting in different trust we place in them.

ABAC (sometimes referred to as Policy Based Access Control or PBAC or Claims Based Access Control or CBAC) was proposed as a solution to these new issues.

As it evolved it was also called Risk Adaptive Access Control (RAdAC). As the model and its application are still emerging, there is currently no widely accepted ABAC model as there are for DAC, MAC and RBAC. Although considerable literature has been published, there is no agreement on what ABAC exactly means.

It is however safe to state, that attributes and policies (made of rules) are used in ABAC to derive access decision. As those attributes my change during run time, the ability is assumed to perform these policy decisions at runtime too.

Figure 3: Agility creeps into the model from the increasingly dynamic corporate context

RBAC vs. ABAC

As discussed above, both approaches RBAC and ABAC have their specific advantages and disadvantages. RBAC trades up-front role structuring effort for ease of administration and user permission review, while ABAC makes the reverse trade-off: it is easy to set up, but analysing user permissions can be problematic.

This insight comes less as a surprise, if we start viewing both models as incomplete fragments, just projections of some richer model. And in fact, rarely does any organization use a pure RBAC or ABAC approach. Typically attributes augment or parameterise roles. They can be used independently to assign basic resources to digital identities, which are not linked to functions performed within the organization.

This view supports the strong impression that the discussions of RBAC vs ABAC tend to search for the right answers to the wrong question. It would rather make sense to ask how much R vs. A should be taken to our xBAC model to best serve our needs.

Implementation

Coming to the above conclusion it is not surprising to find that the ‘inventors’ of RBAC themselves come up with even three different suggestions how to combine RBAC and ABAC.

As D. Richard Kuhn, Edward J. Coyne and Timothy R. Weil, in their article “Adding Attributes to Role-Based Access Control” (IEEE Computer, vol. 43, no. 6 (June, 2010) IEEE Computer, vol. 43, no. 6 (June, 2010), pp. 79-81, pp. 79-81) present, there should be three approaches to handle the relationship between roles and attributes, all retaining some of the administrative and user permission review advantages of RBAC while allowing the access control system to work in a rapidly changing environment:

Figure 4: There are 3 basic models discussed here to combine RBAC and ABAC

Dynamic roles. Attributes such as time of day are used by a front-end module to determine the subject’s role, retaining a conventional role structure but changing role sets dynamically (R. Fernandez, Enterprise Dynamic Access Control Version 2 Overview, US Space and Naval Warfare Systems Centre, 1 Jan. 2006; http://csrc.nist.gov/rbac/EDACv2overview.pdf). Some implementations of dynamic roles might let the user’s role be fully determined by the front-end attribute engine, while others might use the front end only to select from among a predetermined set of authorized roles.
Attribute-centric. A role name is just one of many attributes. In contrast with conventional RBAC, the role is not a collection of permissions but the name of an attribute called role. This approach’s (IEEE Computer, vol. 43, no. 6 (June, 2010), pp. 79-81) main drawback is the rapid loss of RBAC’s administrative simplicity as more attributes are added. It also suffers from potential problems with ABAC when determining the risk exposure of a particular employee position. However this 2^nd scenario could serve as a good approach for a rapid start, generating early results in automatic the assignment of all those permissions, which can be granted without having deeper knowledge of the digital identities job function.
Role-centric. Attributes are added to constrain RBAC. Constraint rules that incorporate attributes can only reduce permissions available to the user not expand them. Some of ABAC’s flexibility is lost because permission sets are still constrained by role, but the system retains the RBAC capability to determine the maximum set of user-obtainable permissions. As an aside, developers explicitly designed the formal model for RBAC, introduced in 1992, to accommodate additional constraints being placed on a role. This approach by the way is the one envisioned as the natural approach by KuppingerCole ).

Conclusion

	In a dynamic role meta model … Roles can be created at runtime So can constraints They are rule / attribute pairs Roles & constraints can be deployed dynamically too. Dynamicity is propagated from constraints and/or from functional roles to business roles and authorisations Entitlements and identities remain static at the same time.
Figure 5: Roles and constraints may be created and / or used dynamically

Having said all this, we can safely conclude that sticking with one model in its pure breed will limit our expressive power and lead to suboptimal results. There should be less the question whether we have a preference for the A or the R in the respective xBAC-model. But rather we should decide on how much of each to be introduced at what point in time. Even a combination of the three approaches as mentioned in the above chapter may not lead to model degeneration but would rather have the potential to lead to an optimal model.

References

D.F. Ferraiolo and D.R. Kuhn (1992) "Role Based Access Control", 15th National Computer Security Conference, October, 1992
M. Blaze, J. Feigenbaum, J. Ioannidis, “The KeyNote Trust-Management System Version 2”, IETF RFC 2704, September 1999
K. Brown, “Exploring Claims-Based Identity”
A. Pimlott and O. Kiselyov, “Soutei, a Logic-Based Trust-Management System”, FLOPS 2006, 8th International Symposium on Functional and Logic Programming.,Fuji-Susono, 12 Japan, April 24-26, 2006. Also in Springer's Lecture Notes in Computer Science 3945/2006, pp. 130-145.
D. Richard Kuhn, Edward J. Coyne, Timothy R. Weil, “Adding Attributes to Role-Based Access Control”, IEEE Computer, vol. 43, no. 6 (June, 2010), pp. 79-81

GenericIAM.org BLOG

2015-10-27

RBAC first – ABAC next, or what?