RBAC (role-based access control)
Also: role-based permissions, roles and permissions
What is RBAC (role-based access control)?
RBAC is an authorisation model where permissions are attached to roles such as admin, manager or viewer, and users are granted roles, so what someone can do depends on their role rather than individual settings.
What RBAC (role-based access control) means
In role-based access control, every action in the product (view invoices, approve refunds, export data, manage users) is a permission. Permissions are grouped into roles, and each user in a tenant holds one or more roles. Checks happen at the API layer, not just in the UI, so a hidden button is never the only thing standing between a user and an action they should not take.
Real products need a few refinements: scoped roles (manager of this branch, not all branches), custom roles that enterprise customers define themselves, and a way to express ownership (you can edit your own draft). When rules depend on attributes of the data rather than the user's role, teams move towards attribute-based or relationship-based access control, but a well-designed RBAC model with scopes covers most SaaS products.
RBAC is not authentication; SSO decides who you are, RBAC decides what you may do. It is also the model AI copilots must respect: an agent acting on a user's behalf inherits that user's role and nothing more.
Who it really matters to
- CISO: least-privilege access is a core control in every security framework, and RBAC is how it is implemented in application software.
- Product manager: role design shapes onboarding and the enterprise admin experience; too few roles blocks deals, too many confuses customers.
- CTO / Head of Engineering: permission checks must be centralised and tested, because scattered if-statements are where privilege bugs live.
- Compliance officer: auditors ask who could access personal or financial data, and a role matrix is the answer.
Why it exists
RBAC exists because managing permissions per user does not scale and cannot be audited. Roles let an administrator reason about access in a handful of named bundles, onboard a new hire by assigning one role, and answer an auditor's question with a matrix. The trade-off is that roles are coarse; some customers will want exceptions, and the temptation to add a special-case flag for each one erodes the model. Scoped and custom roles are the usual middle ground.
Where it is applied
- A B2B SaaS product with owner, admin, member and read-only roles plus customer-defined custom roles for enterprise plans.
- A lending platform where maker and checker roles enforce that the person who enters a loan cannot also approve it.
- A hospital information system where roles map to clinical departments and restrict who can view a patient's full record.
- A retail operations tool where store managers see only their store's inventory and finance sees everything.
- An in-app AI copilot that performs actions only within the permissions of the user who asked.
Is RBAC (role-based access control) a skill?
ConceptAn authorisation model implemented in code and data rather than a specific product. Eazyware designs role models and centralised permission checks as part of SaaS development, and extends them to copilot actions under the SaaS copilots service.
Eazyware service that covers it: SaaS / Cloud-native Application Development. Starting prices are on the pricing page.
Frequently asked questions
How many roles should a SaaS product ship with?
Start with three or four that match how customers actually work, such as owner, admin, member and viewer. Add scoped or custom roles when enterprise customers ask, and resist adding a new role for every edge case.
Where should permission checks live?
In one authorisation layer called by every API endpoint and background job, never only in the front end. Hiding a button is a courtesy to the user; the API check is the actual control, and it should be covered by automated tests.