Software Growth

RBAC (Role-based access control)

RBAC controls what each user can do by assigning them roles, such as admin, editor or viewer, and giving each role a fixed set of permissions.

Instead of setting permissions for every person, you define roles and attach permissions to those. Users get one or more roles. NIST describes the idea as each user assigned one or more roles, and each role assigned one or more privileges. The model was formalized in 1992 by David Ferraiolo and Rick Kuhn, then standardized by ANSI in 2004 and updated in 2012.

A simple example

A project tool for agencies might define four roles:

  • Owner: everything, including billing and deleting the account.
  • Admin: manage users and settings, no billing.
  • Member: create and edit projects.
  • Viewer: read only, often free or cheap. This helps clients see work without paying for a full seat.

With 40 users and 20 permissions, individual settings mean up to 800 switches to manage. With four roles, an admin makes 40 choices.

Why customers ask for it

EnterpriseReady explains that enterprise buyers need different team members to get only the functionality they need to do their job, which is the principle of least privilege. Organizations with compliance programs such as SOC 2 or ISO 27001 expect fine-grained access control and audit trails. Finance wants to see invoices but not edit settings. Contractors should not export the customer list.

Fixed roles vs custom roles

Start with a handful of fixed roles. The usual enterprise request, according to EnterpriseReady, is for customers to create custom roles that combine your permissions for their own structure. Custom roles are more work: you need a permission list that is stable and named well, an interface to build roles, and checks in every endpoint. The same source calls the sophistication of authorization the most obvious differentiator between professional and enterprise tiers of SaaS, which is why custom roles often sit in the top plan.

RBAC and related ideas

  • Groups and SSO: large customers want to map directory groups to roles, usually through SCIM.
  • Attribute-based or resource-level access: "can edit only the projects they own" goes beyond roles, and many products add it later.
  • Audit logs: record who changed a role, so admins can answer "who gave this person access?".

Pricing angle

Roles can shape pricing. A cheap or free viewer role reduces friction in per-seat pricing, since clients and stakeholders can look without becoming expensive seats. Advanced permissions are a standard lever for separating tiers.

When a small SaaS should care

From the first team plan. Two or three roles (admin, member, viewer) are cheap now and painful to retrofit after you have hard-coded "everyone can do everything". Put permission checks in one place on the server, not scattered through the interface. Add custom roles only after several customers ask, and then place them in a higher plan.

Related terms

Sources

Back to the SaaS glossary