Skip to content
// Glossary · Governance

RBAC

Also called: role-based access control, roles and permissions

What is RBAC?

RBAC is role-based access control. Permissions attach to named roles, people are given roles, and what somebody can do follows from the role rather than from a pile of individual grants. Changing what a role may do changes it for everybody holding that role.

// In more depth

Why the indirection is the point.

Roles exist so permission decisions are made once rather than per person.

01

Permissions belong to the role

You decide what an admin may do, not what each admin may do. That decision is reviewable in one place, which is what makes an access model auditable at all.

02

People are assigned, not configured

Granting somebody a role is one action with predictable consequences. Granting fifteen individual permissions is fifteen chances to get it wrong and no way to see what you intended.

03

Drift becomes visible

With direct grants, entitlements accumulate quietly over years and nobody can say why somebody has a permission. With roles, the answer is always the role, and the role is a document.

// Why it matters

What it prevents.

Mostly it prevents the slow accumulation nobody notices.

Reviewable in one pass

Checking four role definitions is a real audit. Checking two hundred individual permission sets is not.

Least privilege stays true

Access follows the job. When the job changes, the role changes, and the permissions follow.

Explains the audit trail

When a log says somebody did something, the role is what explains why they were allowed to.

// Commonly confused with

Commonly confused with.

Three things it is not.

AuthenticationAuthentication decides whether you get in. RBAC decides what you may do once inside. SSO handles the first, and neither substitutes for the other.
SeatsA seat grants access to a product. A role governs what you can do within it. Somebody can hold a seat and still lack the role for an administrative action.
ABACAttribute-based access control decides from attributes and context rather than named roles. More expressive, considerably harder to review, and a different model.
// FAQ

RBAC questions

What is RBAC?

Role-based access control. Permissions attach to named roles and people are given roles, so what somebody can do follows from the role rather than from individual grants stacked up over time.

How is it different from authentication?

Authentication decides whether somebody gets in, which is what SSO handles. RBAC decides what they may do once inside. Separate questions, and neither replaces the other.

Is a seat the same as a role?

No. A seat grants access to a product. A role governs what you can do within it. Somebody can hold a seat and still not have the role for an administrative action.

Why not grant permissions per person?

Because it does not stay reviewable. Entitlements accumulate quietly and nobody can say why somebody holds a permission. With roles, the answer is the role, and the role is a document.

Does Virex support RBAC?

Yes, as part of the platform governance set alongside SSO and SAML, SCIM, audit logging, and retention policy.

Access that follows the job.

Roles, SSO, SCIM, and audit logging are part of the platform.