Concepts You’re Using Without Even Knowing: Role-Based Access Control

Welcome to our new series about technical concepts and features that you’re probably using every day without even knowing about it. We are running this series so that you get a deeper understanding of how these concepts impact your day-to-day operations, and how to make the best use of the tools at your disposal.

Our first article is about role-based access control, a commonly used way to manage application permissions and access to network resources based on the role allocated to a user. It’s also known as role-based security and it’s a concept every sysadmin should fully grasp.

What is role-based access control?

Role-based access control evolved out of the need to manage increasingly complex access control lists across large numbers of users and resources. Let’s take a step back and look at access control first.

Why we need access control

For fairly obvious reasons sysadmins will want to limit the ability of users on a system to take actions on that system. When we use the word users, we refer both to human users as well as applications that act as users of services.

Access control acts as a layer between users and systems, ensuring that systems administrators can put in place limits – without completely restricting functionality.

A range of systems is covered by access control – from access to the operating system and applications to access to specific networks both internal and external. And yes, as a first step, access control tells us whether a user can access an application, system, or network – or whether access is not allowed for that user.

Access control is also about the degree of access that is granted. In other words, one user may have comprehensive access to a system – read and write, for example – whereas another user may have restricted access – just read, for example.

All of these concerns are cross-cutting across the operating system and application space. An individual application that supports multiple users will probably require some form of control over which users can perform which activities (or it will stop being useful very quickly).

The need for advanced access management

In simple systems a straightforward access control list will do the job – listing which users have what type of access and where. But in today’s complex enterprise IT environment long lists of access control criteria will not work – particularly given the integrated nature of systems and the way in which permissions in one place also require permission to propagate elsewhere.

At its core, RBAC is an abstraction layer that separates permissions from users by introducing the concept of “roles”, which are also known as “groups”. This apparently small change permits greater flexibility and granular control of permissions. In some ways, role-based access control adds some administrative overhead, but when looking at the broader picture, RBAC makes access management much simpler particularly in more complex environments.

What is a role?

Roles are central to RBAC. Just like users, a role can refer to an individual’s role in the organization and therefore the systems permissions required to perform that role. Roles can also be assigned to inanimate objects such as applications or services running on a server.

When it comes to access control, a specific role will define a specific set of permissions. For example, an “editor” will be able to read and edit articles on a website, but won’t be able to change the website settings or to delete articles – that would require an “administrator” role.

By making use of roles, sysadmins can ensure that individuals that need specific access rights to do their jobs have those rights according to a set template – as defined by the role. When a new editor joins the company, for example, a sysadmin can simply assign the standard editor role without the need to manually configure the new staff member’s permissions.

Seen another way, junior employees – including, for example, junior systems administrators – would have fewer access rights to a company’s systems. Junior employees will have access to just a subset of a company’s information, and junior sysadmins will have permission to make some changes to systems – but not all.

Furthermore, roles relate permissions to resources. So, a role can link certain permissions to specific resources. For example, someone working in the New York office can access cloud-based resources related to the NYC office based on their NYC role. The same person can’t access resources for San Francisco unless their role is expanded due to the involvement in a project in San Francisco.

Roles can be used in incredibly flexible ways. For example, role composition is where one individual is assigned multiple roles, inheriting permission across all the roles. Composition can happen quite naturally as users are assigned roles to match their sometimes complex position inside of an organization.

RBAC: access control using roles

So, as the acronym suggests, RBAC applies access control based on the role or indeed multiple roles assigned to a user. It is an improvement on standard access control lists and of course, RBAC is just one model for access control.

There is an alternative in so-called attribute-based access control (ABAC) which evolved from RBAC. ABAC grants access based on the attributes of the subject (user) and the resource being accessed – as well as a few other elements including the action required and the environment in which the request is made.

How to determine if your system uses RBAC

Most applications that support multiple users will have some form of control for specifying which users can do what. If an application or system refers to groups and if users get added to a group rather than being assigned permissions individually then that application or system uses RBAC. Essentially, look out for words like groups and roles and you’re probably in RBAC technology.

Examples of role-based access control in practice

Role-based access control is incredibly common. It is easy to use and easy to implement, and you’ll find it embedded in your technology solutions right from OS level to the everyday applications and services that you use. In this section we’ll look at some common examples of RBAC.

At a simple level, consider a content management system. Here, users need to be able to manage content – create and edit articles, delete articles and edit the structure of the site. The author role, for example, could include the ability to create and edit articles – but not delete articles.

Workers with an editor role may be able to edit and delete articles – but not modify the site structure. The administrator role, in turn, would have full permissions – creating, editing, deleting articles as well as the ability to alter the site structure and settings.

RBAC is also commonly used as a gatekeeper for data. Consider medical data, for example, where certain medical staff with specific roles are given access to patient data – while other staff members may only be able to see a subset of the data or only the data from patients that they are consulting.

Moving on to the tech world, Kubernetes, the commonly used containerization solution, uses RBAC to ensure that both human users and applications have the right level of access to individual containers and groups of containers.

RBAC also operates at a very overarching role in cloud platforms such as Microsoft’s Azure, where RBAC regulates access to Azure resources and the applications running on those resources.

Benefits of using RBAC

Why would you want to use RBAC instead of a simple ACL? We’ve hinted at some of the benefits but let’s take a closer look at the benefits that make RBAC such a common way to enforce permissions.

Operational efficiency

While ACLs can technically do the job, ACLs quickly become cumbersome and eventually become unworkable as permissions complexity builds. However even with simpler workloads RBAC simply does a better job of managing permissions because rules do not need to be set on a user-by-user basis.

For example, with an ACL, if you want to allow all users to print to a specific printer, this change would have to be done on each individual user. With RBAC, you simply add the printer to the relevant group.

The above is just a simple example – where RBAC is deployed in large complex systems, the operational efficiencies truly scale. In fact, very large organizations simply cannot function without RBAC – relying on ACLs would simply be unworkable.

Integration with other services

RBAC with its catalog of users, roles and permissions can also act as a platform for a permissions database, or directory service. It means that an RBAC-based access control system can easily integrate across different services.

In other words, roles and user permissions can be retrieved one by one or even exported wholesale to then be applied to a completely separate system, which means that RBAC offers plenty of opportunities for integration across systems.

Improved control and compliance

Where RBAC is used administrator can apply more granular and more frequent control over permissions. Permissions can be managed more flexibly too, which means that administration can exercise tighter control over permissions.

Particularly in large-scale deployments, permissions can become quite “loose” and “excessive” over time. RBAC, therefore, helps tighten access which improves compliance with both organizational rules and policies – and the wider compliance environment. Rules can be closely aligned with compliance requirements and are easier to change in case regulations change.

Auditing and visibility

In the case of enterprise-scale applications, RBAC will most probably also keep sophisticated access logs to help administrators understand what access was granted to who, by who it was granted, and when it was granted.

It gives significantly higher visibility into how systems are accessed and by who they are accessed. Furthermore, solutions that use RBAC should also be able to export reports giving sysadmins clear insight into which users have what type of permissions.

Disadvantages of using RBAC

As with any approach in information technology, there are some disadvantages to using RBAC. First, there is the initial “cost” of needing to select roles for users when a user is added. However, given how easy RBAC makes it to propagate roles-based permissions for that user in the future it can be seen as a relatively minimal cost. This is usually dealt with by some form of integration with an already established business roster or centralized identity management service.

One issue with RBAC can be something called role explosion – as more and more roles are created to accommodate an increasing number of roles in the organization and to account for increasingly complex roles inside the organization. It can lead to a great deal of complexity which can be challenging to manage.

Setting up RBAC role structures can also be quite time-consuming and complex. Furthermore, as an organization changes, this structure will change too – which can mean that the structure of roles needs to be reviewed every few years.

For these reasons some people see ABAC as an improved alternative that is better suited to highly complex access and permissions environments.

Setting up RBAC

One way to get past some of the drawbacks of RBAC is to start off with a well-structured RBAC configuration. Here are some tips to help you along the way:

• Start by thoroughly cataloging. Before you start thinking about roles, make sure you know exactly what systems you’re trying to set permissions for. Think about networks through to the different databases in your organization. It’s important to know what you’re trying to control access to before you design your access control system.
• Analyze your workforce. Examine your workforce closely and try to identify clear roles – and even overlapping roles. In doing so you need to carefully balance creating enough roles so that your permissions structure is sufficiently granular, but not so many that you defeat the benefits of RBAC by using too many roles.
• Get your colleagues on board. Next, set access for your workers according to their everyday responsibilities by matching these responsibilities to roles. It is also worth setting up a degree of training for your colleagues – particularly those in technology roles – so that they understand the basics of RBAC.
• Manage for change. Dealing with changing roles is one of the more challenging aspects of RBAC. When planning your RBAC system, plan for how roles may change in the future, and do regular audits to ensure that the roles and permissions you have configured still matches up to reality on the ground.

In essence, a bit of forward-thinking will help you get the most of RBAC and minimize the changes and maintenance you need to do in the future.

Conclusion

RBAC is one of the ways in which you can manage users and permissions across your applications and your systems. The high-level concepts involved in RBAC, including users and groups as well as rules and policies, cuts across technology topics.

It is worth understanding what the purpose is of each of these cross-cutting concepts and how these works in other areas of the IT field. As IT professionals understanding the fundamentals helps us to deal more competently with the more complex topics.