TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

Divide and Control: Roles vs. Rules in Access Management

Role-based access control is the norm in many companies, but binding users to statically defined roles is an inflexible approach. Attribute-based control offers more opportunity and flexibility to get security right.

• By Cass Brewer
• March 10, 2016

Access management is basically gatekeeping: managing who (or what) in an ever-changing user base can access specific things or processes in an ever-changing systems environment. Role-based access control (RBAC) is one of the most common approaches, with good reason. The logic of “if user is type a, they can do x but not y” is simple and easy to build into software. If you're not too picky about security, just a few generic roles (user, admin, superadmin) can cover most of your use cases.

It's no surprise, then, that most companies have at least basic RBAC on significant software, and databases. Complex or highly sensitive systems environments, however, can reveal some of RBAC's limitations, and poor implementation can further degrade its effectiveness.

For one thing, roles often only loosely match what users actually do. In an ideal world, roles would be defined by business or process managers who understand what system users need to do. Reality-based companies, however, often delegate the task to IT or security managers, who are more interested in what systems do (and who tend not to trust users). This awkward misalignment can end up disempowering users, adding administrative process, and ultimately reducing the business value of a system.

RBAC also tends to be functionally insensitive. Roles are rigid: user a gets access to resource y, regardless of what they're doing or why. When companies process lots of data, however -- including different kinds of data, and especially if some of that data is sensitive -- a more nuanced and contextually sensitive control system can help ensure that everyone has access to all of the data they need, but only the data they need (least privilege, in security parlance) for a specific purpose.

To some degree, you can mitigate RBAC's issues by defining increasingly more granular roles and/or ad hoc roles with limited memberships to fit emergent needs. Still, the overhead of maintenance and propagation -- particularly in the too-common context of developers hard-coding specific roles into software authentication routines -- quickly grows overwhelming.

For these reasons, at least, using RBAC often means that something has to give: you end up generalizing roles, generalizing resource definitions, or generalizing security needs (or you end up with an unmanageable number of role definitions).

We Need a More Flexible Approach

As an alternative or supplement to RBAC, enterprises are increasingly turning to attribute-based access control (ABAC) models that supplement, and sometimes replace, RBAC systems. Attributes are effectively anything you can discovery or define about a user, their environment, or operational conditions. As the name implies, ABAC assigns permissions based on one or more attribute criteria.

ABAC systems typically control access with rules (also called policies) that define how access logic assesses and responds to selected attributes. In contrast to roles, which are essentially just collections of permissions to access system resources, rules define conditions for permission assignments.

What does this mean in practical terms? Rule writers can cherry-pick which attributes and conditions are important in a given process. Rules can also change how the system responds based on a nearly infinite permutation of attributes (per processing constraints). Finally, rules can be defined at any level of a system with any granularity. This gives ABAC a lot of flexibility that can be especially handy in dynamic business and development environments.

Anatomy of an Access Rule

What are these rules that lie at the heart of ABAC? You can think of them as sets of if/then statements. For example, a simple rule based on a user attribute might be:

If user works in the Seattle office, allow access to Seattle Proposal Database.

Here, you could substitute “Seattle office” with any user attribute or combination, such as department, professional certification, office location, team, training completed, role, responsibilities, or years on the job. Then you can crank it up a notch.Because ABAC is a multicriteria access model, it can assess many attributes at a time, potentially including nested rules or complex “else” branching. These rules can encompass a staggering variety of criteria beyond user attributes:

• Environmental: User's IP, VPN, consistency with user's registered work hours, geographical location, browser type, age of account on system, current system load, number of concurrent users, physical proximity of user to another system, etc.
• Historical: Timing or frequency of previous access attempts, last performed action, required action performed, previous workflow, etc.
• Resource-related: Type of resource, security classification, label, currency, age, etc.
• Operational: Relevance request with operation being performed, approval requirement, required segregation of duties, etc.

Basically you're limited only by your imagination and technical processing constraints.

Of course, such great power demands great responsibility. Data managers, process managers, and other operational “experts” must engage in defining access access rules. Most of the benefit of ABAC over RBAC lies in its ability to more closely align access permissions to what is actually in data, who uses it, and how.

Finally, as you might guess, ABAC offers plenty of opportunity for complexity, too. Rules, like roles, tend to proliferate when needs change. The incremental process burden can be much lower for ABAC, however. Because rules are an abstraction layer between users and systems, tweaking or adding a rule doesn't change the relationship between the two. With roles, both the user membership in the role and permission assignments are toggles: all-or-nothing. Changing the access logic often means either reassigning the user to a different role or changing the role's relationship to systems. ABAC lets you tweak conditional access logic without breaking those relationships.

For more information on RBAC, ABAC, and how the two can work together, check out these in-depth papers:

ABAC and RBAC: Scalable, Flexible, and Auditable Access Management, by Ed Coyne, DRC, and Timothy R. Weil, Coalfire. (Originally published in IEEE Insecure IT, May/June 2013.)

NIST Attribute-Based Access Control (ABAC) -- Overview.

NIST Special Publication 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations.

Specification and Verification of an Attribute-based Usage Control Approach for Open and Dynamic Computing Environments (dissertation) by Christos Grompanopoulos.