What Is Role-Based Access Control (RBAC)?

TL;DR

Role-based access control (RBAC) is a security model that ties system permissions to job roles rather than individuals. Adopted as an industry standard in 2004, RBAC simplifies administration by letting organizations grant, update, or revoke access for entire groups at once. Key components include administrators, roles, and permissions (covering access, reading, writing, sharing, and finances). RBAC reduces complexity, lowers costs, and eases onboarding. For organizations needing more granular control, attribute-based access control (ABAC) offers an alternative. Successful implementation requires careful inventory, role definition, stakeholder collaboration, and a phased rollout.

Understanding role-based access control 

Role-based access control (RBAC) systems assign access and actions according to a person's role within the system. Everyone who holds that role has the same set of rights. Those who hold different roles have different rights.

Why does a system need RBAC?

Every company has sensitive documents, programs, and records. Protect them too strictly, and your company's work grinds to a halt. Leave them open, and catastrophic security issues can arise. 

Enter role-based access control (RBAC).

Use this method to grant access to those who need it while blocking those who don't need access. Make changes based on a person's role rather than individual attributes. You can make these changes quickly by altering access by role.

If you work in information technology (IT), understanding the ins and outs of role-based access control is critical. In 2004, the American National Standards Institute adopted RBAC principles as an industry consensus standard. Chances are, you'll either need to apply RBAC or explain why you think it's a bad idea for your company.

What exactly is role-based access control?

All role-based access control systems share core elements:

• Administrators. They identify roles, grant permissions, and otherwise maintain security systems.
• Roles. Workers are grouped together based on the tasks they perform.
• Permissions. Access and actions attach to each role, and they outline what people can and cannot do.

RBAC systems do not require the following:

• Differentiation of individual freedoms. Access is defined by a person's role, not that person's preferences or wishes. This makes it easy to manage permissions.
• Intensive maintenance. Permissions follow roles. A new job function becomes a new role applied to dozens (or hundreds or thousands) of employees with only a small amount of work for the administrator. Promotions involve changing roles, not editing permissions as line items.

How did RBAC originate?

RBAC systems have been around for decades. In 1992, RBAC concepts were introduced in a national computer security conference. The originators felt that mandatory access controls and discretionary access controls just didn't work well for private companies and civilians because specific needs and security requirements varied so much. The new method, they argued, worked better in non-military, civilian settings. 

Since then, thousands of companies have applied RBAC concepts to manage security for their most sensitive documents. 

How do roles work within RBAC?

Roles dictate authorization within an RBAC system. It's critical to define them properly. Otherwise, large groups of people within your company can't do their work. 

Roles can be defined by:

• Authority. Senior management needs access to files interns should never see.
• Responsibility. A board member and a chief executive officer (CEO) might hold similar authority within a company, but they are each responsible for different core functions.
• Competence. A skilled worker can be trusted to work within sensitive documents without errors, while a novice could make catastrophic mistakes. It's important to tailor access accordingly.

Roles can also have overlapping responsibilities and privileges. For example, someone with the role "surgeon" might also work as a "doctor" or "radiograph interpreter." A role hierarchy defines one type of person who holds the attributes of many other people. In other words, one role can hold many others inside it. 

What are role-based access control permissions?

Permissions specify what people can access and what they can do in the system. Think of permissions as the rules people follow per the roles you have outlined.

Your permissions should involve:

• Access. Who can open a specific drive, program, file, or record? Who shouldn't even know these things exist? Access will limit what people can see.
• Reading. Who can scan through these documents, even if they can't change anything inside of them? Some roles may have the ability to reference materials but not make changes to them.
• Writing. Who can change documents? Does someone else have to approve the changes, or are they permanent? You'll define this with your permissions.
• Sharing. Who can download a document or send it as an email attachment? As with the other permissions, some users will not be able to share materials even if they can reference them.
• Finances. Who can charge money? Who can offer refunds? Permissions could involve the ability to deal with charges and refunds, set up credit accounts, or cancel payments.

Why permissions must follow roles, not individuals

It's critical to remember that permissions follow roles, not the other way around. Determine what each role should do, and apply permissions accordingly.

Don't allow employees to demand permissions despite the limitations of their current role. If you begin to alter permissions on an individual basis, the system can quickly get unwieldy. 

What are the benefits of role-based access control?

Security options abound, and it's not always easy to make the right choice for your company. RBAC comes with plenty of tried-and-true benefits that set it apart from the competition.

An RBAC system can:

• Reduce complexity. New employees gain access based on their roles, not on long lists of server and document requirements. This simplifies creating, maintaining, and auditing policies
• Allow global administration. Change access for many employees all at once by altering permissions associated with a role. 
• Ease onboarding. As people join, move within, or are promoted within your organization, you don't have to worry about the individual's permissions, just that they're in the right place. The roles take care of the rest.
• Reduce blunders. Traditional security administration is error-prone. Adding permissions for individuals gives you plenty of options to make a mistake. Change a role's access, and you're less likely to give someone too much (or too little) power.
• Lower overall costs. When admin duties shrink, companies save on security administration. This saves your organization time and money. 

RBAC vs. attribute-based access control (ABAC): which is better?

Before we dig into the nitty-gritty of applying a role-based access control model, let's discuss an alternative. ABAC is one of the best-known models companies consider, and it could be useful in some settings.

ABAC, or attribute-based access control, explodes your role options. Rather than considering job titles, seniority, and similar attributes, you could consider:

A system like this leans on policies to enforce security rather than static permission types. Getting the balance right is slightly more difficult, as more variables are involved. Depending on your security environment, it could be a smart choice for your organization.

How to implement an RBAC system

Like most security tasks, crafting a role-based access control system is a methodical process. Each step must be completed in order. You may need quite a bit of input to do the job right.

To create the right system, you must:

1. Inventory your system. Determine the programs, servers, documents, files, and records that are part of your business landscape. Take some time to think this through, as you don't want to leave anything out.
2. Identify roles. Collaborate with management and human resources. Determine how many roles make sense for your company, and identify permissions based on those roles.
3. Develop an integration timeline. Determine how long you will need to put your program to work, and give your colleagues time to prepare. Don't roll out your changes without notifying workers, or you could grind progress to a halt.
4. Remain open to feedback. Circulate your plans for roles and permissions. Ask managers if your assumptions are correct, and make adjustments accordingly.
5. Implement the plan. With roles and permissions identified, put the plan to work. Watch the network closely and fix glitches if they appear.

Follow a few best practices to ensure your project's success.

Best practices for a successful RBAC rollout

• Take your time. Even tiny companies have hundreds of role/permission combinations. Plan very carefully and give yourself time to adjust your plans before you put them to work.
• Stand firm. Chances are, users will come to you and ask for permissions outside of their roles. Consider each request carefully before giving individual users additional permissions. Take note of these requests, and ask management if everyone in the role should have access to the requested files. You want to avoid users who hold the same roles having drastically different levels of access.
• Collaborate often. Too-tight security rules lead to systems that aren't useful for end users. Don't deny requests without thorough investigation and collaboration. Strike a balance to keep the company working safely. 

Work with an expert

Implementing a program like this can feel intimidating, but the work can be very manageable with a little assistance. Use a platform like Okta to simplify the process. Okta integrates with over 6,500 apps so everything is centralized, making the process straightforward for your organization.

Frequently asked questions

What is the difference between a role and a permission in RBAC?

A role is a grouping of workers based on the tasks they perform — such as 'surgeon' or 'board member' — while a permission defines what actions that role can take, such as reading, writing, sharing, or accessing specific files. Permissions follow roles, not individuals.

Can a user hold more than one role in an RBAC system?

Yes. RBAC supports overlapping responsibilities and privileges across roles. For instance, a person assigned the role of 'surgeon' may simultaneously hold the roles of 'doctor' or 'radiograph interpreter.' Role hierarchies make it possible for a single role to encompass the attributes of several others.

What happens if an employee requests permissions outside their assigned role?

Administrators should carefully evaluate each request before granting individual exceptions. It is best practice to consult management and determine whether everyone in that role should have the requested access, rather than creating inconsistent permission levels among users with the same role.

How is RBAC different from attribute-based access control (ABAC)?

RBAC grants access based on job roles, authority, and responsibility. ABAC expands on this by incorporating additional variables such as user type, time of day, and location. ABAC offers more granular control but is more complex to configure and maintain.

How long does it take to implement an RBAC system?

Implementation timelines vary by organization size and complexity. The process involves inventorying systems, identifying roles, collaborating with management and human resources (HR), communicating changes to staff, and iterating based on feedback. Even small companies can have hundreds of role-and-permission combinations, so careful planning and adequate time are essential.

What are the main cost benefits of using RBAC?

RBAC reduces the administrative burden of managing individual permissions, which lowers security administration costs. It also simplifies onboarding and role changes, meaning less time is spent on manual permission updates — saving the organization both time and money.

References

Role Based Access Control (RBAC). (June 2020). National Institute of Standards and Technology, U.S. Department of Commerce. 

Conference Proceedings: Role-Based Access Controls. (November 1992). National Institute of Standards and Technology, U.S. Department of Commerce.

An Introduction to Role-Based Access Control. (December 1995). National Institute of Standards and Technology, U.S. Department of Commerce.

Role-Based Access Control (RBAC): Permissions vs. Roles. (February 2018). Medium. 

Role-Based Access Control Project Overview. (June 2020). National Institute of Standards and Technology, U.S. Department of Commerce.

Role-Based Access Control (Presentation). National Institute of Standards and Technology. 

An Evolution of Role-Based Access Control Towards Easier Management Compared to Tight Security. (July 2017). ICFNDS '17: Proceedings of the International Conference on Future Networks and Distributed Systems.

Authorization and Access Control. (2014). The Basics of Information Security (Second Edition).

Security for Distributed Systems: Foundations of Access Control. (2008). Information Assurance: Dependability and Security in Networked Systems.

Access Controls. (2013). Computer and Information Security Handbook (Third Edition).

How to Implement Role-Based Access Control. (October 2007). Computer Weekly.

Role-Based Access Control: Meek or Monster. Wired.

Guide to Role-Based Access Control (RBAC). IBM Support.

Extending RBAC for Large Enterprises and Its Quantitative Risk Evaluation. Mitsubishi Electric Corporation.

Restricting Database Access Using Role-Based Access Control (Built-In Roles). Amazon Web Services (AWS).

An Enhancement of the Role-Based Access Control Model to Facilitate Information Access Management in Context of Team Collaboration and Workflow. (December 2012). Journal of Biomedical Informatics.

Identify Governance and Role-Based Access Control. University of Michigan Information and Technology Services.