Role-Based Access Control (RBAC)

Role-based access control (RBAC) is a security model that grants users access to a system based on their role in an organization, not on their individual identity. Permissions are attached to roles such as “Admin” or “Viewer”, and users receive permissions only by being assigned a role. This makes access predictable to grant, review, and revoke as people join, change jobs, or leave.

How Role-Based Access Control Works

RBAC separates who a person is from what they can do, using a role as the layer in between.

The model has four building blocks, as defined in the ANSI/INCITS 359-2004 RBAC standard:

• Users. The people (or service accounts) who need access.
• Roles. Named job functions, such as Editor or Billing Manager.
• Permissions. An approved operation on an object: edit on a campaign link, delete on a report.
• Sessions. The roles a user has activated while logged in.

Permissions are never assigned directly to users. An administrator assigns permissions to roles once, then assigns users to roles. When a new hire joins the content team, they get the Editor role and inherit every Editor permission in one step. When they leave, removing that single assignment revokes everything.

The model was formalized by David Ferraiolo and Richard Kuhn at NIST in 1992 and became an ANSI standard in 2004.

RBAC Example

A marketing team managing campaign links typically needs four roles. Each one maps to a real job, not a person.

Role	Create links	Edit templates and rules	Delete links	View reports	Manage members
Admin	Yes	Yes	Yes	Yes	Yes
Editor	Yes	Yes	Yes	Yes	No
Creator	Yes	No	No	Yes	No
Viewer	No	No	No	Yes	No

The same policy in the structure most systems store it:

{
  "roles": {
    "admin":   ["link:create", "link:delete", "template:edit", "report:view", "member:manage"],
    "editor":  ["link:create", "link:delete", "template:edit", "report:view"],
    "creator": ["link:create", "report:view"],
    "viewer":  ["report:view"]
  }
}

An intern assigned Creator can build tagged links all day but cannot change the naming template the rest of the team depends on. An agency client assigned Viewer sees results without touching anything. This is the setup behind role-based access for link management in linkutm.

Types of RBAC

The ANSI standard defines four components, each adding a capability on top of the last.

1. Core RBAC. Users, roles, permissions, and sessions. Every RBAC system implements at least this.
2. Hierarchical RBAC. Roles inherit from other roles. An Editor automatically holds every Creator permission, so shared permissions are defined once.
3. Static separation of duty. Conflicting roles cannot be assigned to the same user. Someone who creates vendor payments cannot also hold the role that approves them.
4. Dynamic separation of duty. A user may hold conflicting roles but cannot activate both in the same session.

Most SaaS products implement Core RBAC with a light hierarchy. Separation of duty appears mainly in regulated industries.

Why Use Role-Based Access Control

RBAC enforces the principle of least privilege: each person gets exactly the access their job requires, and no more.

Three practical benefits follow:

• Faster onboarding and offboarding. One role assignment replaces dozens of individual permission grants.
• Fewer access errors. OWASP ranks Broken Access Control as the number one web application risk in its 2021 and 2025 Top 10 lists. Centralizing permissions in roles reduces the one-off grants where those errors hide.
• Easier audits. Reviewing six roles is feasible. Reviewing 400 individual permission sets is not.

The economic case is documented. A 2010 study by RTI International for NIST estimated RBAC had produced $6.1 billion in net economic benefits for U.S. industry, driven mostly by less time spent administering access. Pair RBAC with an audit log: roles control who can make a change, the log records who actually did.

RBAC vs ABAC

RBAC decides access by role. Attribute-based access control (ABAC) decides it by evaluating attributes of the user, the resource, the action, and the environment at the moment of the request.

	RBAC	ABAC
Access decided by	Assigned role	Attributes plus policy rules
Example rule	Editors can delete links	Editors can delete links in their own region during business hours
Setup effort	Low	High
Granularity	Coarse	Fine
Main risk	Role explosion	Policies too complex to audit
Defined in	ANSI/INCITS 359-2004	NIST SP 800-162 (2014)

Choose RBAC when job functions are stable and clearly separated, which covers most teams under a few hundred people. Choose ABAC when access depends on context such as location, device, time, or data sensitivity. Many systems combine them: roles set the baseline, and attributes add conditions on top.

RBAC Best Practices

1. Start with job functions, not people. Define roles from what work needs doing, then assign people to them.
2. Keep the role count small. Role explosion, where a team creates a new role for every exception, is the most common RBAC failure. If roles outnumber job functions, consolidate.
3. Default to the lowest role. New members start as Viewer or Creator and get promoted when needed.
4. Review assignments quarterly. People change teams and keep old roles. Scheduled reviews remove access nobody needs anymore.

Frequently Asked Questions

What is RBAC?

RBAC, or role-based access control, is a way of managing system access in which permissions are assigned to roles and users are assigned to roles. A user can only do what their role allows. It replaces granting permissions person by person, which becomes unmanageable as a team grows. Most business software, from cloud platforms to marketing tools, uses some form of it.

What is the difference between RBAC and ABAC?

RBAC grants access based on a user’s assigned role, while ABAC evaluates attributes such as department, location, time, and resource sensitivity against policy rules. RBAC is simpler to set up and audit. ABAC offers finer control but needs more policy design. Many organizations use RBAC as the baseline and add ABAC rules where context matters.

What is the difference between RBAC roles and permissions?

A permission is a single allowed action on a specific object, such as editing a link. A role is a named bundle of permissions that matches a job function, such as Editor. Users are given roles, never raw permissions. Changing a role’s permissions updates access for everyone who holds it at once.

What is an example of role-based access control?

A common example is a shared marketing workspace with Admin, Editor, Creator, and Viewer roles. Creators can build links but cannot change templates, and Viewers can only read reports. A hospital system is another: nurses can view patient charts, while only physicians can write prescriptions.

To give each member of your team the right level of access to campaign links, set up linkutm team workspaces with role-based permissions.