How does Role-Based Access Control (RBAC) work, and why is it better than direct user-to-rights assignment?

Users get assigned roles; roles get assigned rights. The role is an intermediate layer that decouples user identity from permissions.

The model:

Subject (user)  →  Role  →  Rights  →  Objects
   Fred         Administrator    Admin    Directory
   Tom          Engineer         View, Control    Status, Switching
   Mary         Operator         Control, Reporting, Read    All

Two assignments are maintained separately:

• Subject-to-Role (dynamic — who has which job today)
• Role-to-Right (more static — what an "Operator" is allowed to do)

Why this beats direct user-to-right assignment:

• Joiners/leavers are easy: assign Mary the Operator role, all her permissions follow. Revoke the role when she leaves; all access dies at once.
• Audits are easier: you review the small set of role definitions, not every user's individual permissions.
• Consistency: five Operators all have identical rights — no drift over time.
• Without RBAC: every time a user joins, you have to manually click in each system to add the right permissions, and the data drifts immediately.

Static vs dynamic roles:

• Static: fixed by job — Administrator vs regular user.
• Dynamic: acquired by context — strongly authenticated users get more functions than weakly authenticated; a user in the building sees different things than one over VPN.

Tip: Active Directory groups, AWS IAM roles, Kubernetes RBAC, GitHub team permissions — all are RBAC at heart.