Role-Based Access Control Explained

The basic idea

Imagine managing access for fifty people across a dozen systems by granting each person individual permissions. Every new starter needs a long list of requests, and every change means more. Role-based access control, often abbreviated RBAC, offers a tidier approach. Instead of attaching permissions to people, you attach them to roles that reflect jobs, and then assign people to roles.

Three ideas make up the model:

• Permissions: specific actions on specific things, such as “view invoices” or “approve purchase orders”.
• Roles: named bundles of permissions, such as “accounts payable clerk” or “sales representative”.
• Users: people who are assigned one or more roles and receive the permissions of those roles.

When someone is hired into accounts payable, the administrator assigns the role, and the permissions follow. When they leave the role, removing it takes away the permissions in one step.

A simple illustration

The following is an invented example for illustration only. Suppose a small company has three roles.

A new billing clerk gets one role assignment, not three separate permissions. If the company later decides that billing clerks should also see customer credit notes, it changes the role once, and every billing clerk is updated. Notice also that nobody holds both “create invoices” and “approve payments” through these roles alone, which may be intentional in a business that wants those duties separated.

Why organizations use it

• Simpler administration. Requests become “give her the clerk role” rather than a list of permissions.
• Consistency. People doing the same job receive the same access, which reduces accidental differences.
• Easier starts and moves. A new joiner has a clear starting package, and a role change replaces one bundle with another. This helps with the mover problem described in the article on joiners, movers and leavers.
• Clearer reviews. Reviewers can check whether a role is appropriate for a person, rather than examining dozens of individual rights. This makes access reviews more manageable.
• Support for least privilege. Roles that are designed carefully help to give people what the job needs and nothing more.

Designing roles

Good roles start from how the business works, not from the technology. A common approach is to look at job functions, list the tasks each performs, and map those to permissions in each system. Some practical points:

1. Involve the people who know the work. Managers and system owners understand which tasks belong together. IT alone cannot decide this.
2. Keep roles understandable. A role name should tell a manager what it is for.
3. Name an owner for each role. Someone must be responsible for keeping its contents sensible.
4. Build in layers. Many organizations combine a basic role that everyone receives, such as email and the intranet, with job-specific roles on top, and occasionally a few additional roles for particular duties.
5. Document the purpose. Notes on why a role exists help future reviewers.

Where role sprawl creates problems

RBAC works well when the number of roles is manageable. Problems arise when roles multiply, a pattern often called role sprawl or role explosion.

It tends to happen like this. A person needs access that does not quite match an existing role. Instead of changing a role, which may affect others, an administrator creates a new, slightly different one. Repeating this over years produces hundreds of near-duplicate roles, some with unclear names, some with no remaining members, and some that overlap in confusing ways.

The consequences include:

• Nobody can say confidently what a role grants, which defeats the clarity RBAC is meant to provide.
• Reviewers cannot judge roles they do not understand and tend to approve them as they are.
• Retired roles linger, holding permissions that no longer fit any job.
• People collect several roles over time, so their combined access exceeds what any single job requires.
• Conflicting combinations, such as roles that together allow someone to both raise and approve the same payment, go unnoticed.

Keeping sprawl in check

• Set a rule that new roles need justification and an owner.
• Review roles periodically for use, duplication and relevance, as well as reviewing the people in them.
• Retire empty or obsolete roles.
• Use a small number of broad roles plus a few add-ons rather than one role per individual variation.
• Consider handling true one-off cases through time-limited, approved exceptions, not permanent new roles.

Limits of the model

RBAC is not a complete answer. Some decisions depend on context that roles cannot express, such as “only for customers in this region” or “only during a shift”. Organizations sometimes supplement roles with attribute-based rules for those cases, which adds complexity. Roles also reflect the structure at the time they were designed; if the business reorganizes, they need updating.

There is a central-versus-local trade-off as well. A central team that designs roles can ensure consistency across systems, but it may not know the specifics of each department’s work and can become a bottleneck. A federated approach, in which the center sets the framework and local owners define their own roles within it, often fits larger organizations better. Roles are part of authorization, so they only work properly when authentication and the other access processes do their part too.

Role design for important systems is worth discussing with security and compliance professionals, particularly where separation of duties or regulation is involved.