Episode 23 · Module 6 · Authorization & Access Control

RBAC — Roles, Permissions and Scopes

19 May 2026 · 8:44 · Security for Legal SaaS

8:44 8:44

Authentication answers "who are you?" Authorization answers "what are you allowed to do?" In Episode 22, we covered how SSO and SAML let firms manage who can log in. But once a user is authenticated, your application must decide what they can see, edit, delete, and administer. Get this wrong, and a junior paralegal can access partner-level billing data — or worse, a client can view another client's privileged litigation strategy.

Today’s Lesson

Security for Legal SaaS — Episode 23: RBAC — Roles, Permissions and Scopes

The Authorization Problem

Broken access control is the #1 vulnerability in the OWASP Top 10, found in 94% of applications tested.¹ It's not exotic. It's the most common security failure in web applications, and legal SaaS — with its complex hierarchy of firms, departments, matters, and privilege levels — is particularly exposed.

What Is RBAC?

Role-Based Access Control (RBAC) is an access control model where permissions are assigned to roles, and users are assigned to roles. A user inherits all permissions associated with their assigned roles. The model was formalised by David Ferraiolo and Rick Kuhn in 1992 and adopted as ANSI/INCITS 359-2004, the American national standard for RBAC.²

The core abstraction is simple:

User → Role → Permission → Resource

Instead of assigning permissions directly to each of 500 users, you define a handful of roles, assign permissions to those roles, and assign users to roles. When a new associate joins, you assign them the "Associate" role — they instantly get every permission an associate needs, and nothing more.

Designing Roles for Legal SaaS

A legal SaaS platform typically needs a role hierarchy that mirrors how law firms actually operate:

Role	Typical Permissions	Example Actions
Firm Administrator	Full system configuration, user management, billing	Create users, configure SSO, export audit logs
Partner	Full matter access within their practice group, financial data	View billing rates, approve write-offs, access all matters in their group
Senior Associate	Matter-level access, document editing, limited admin	Edit documents, manage deadlines, assign tasks to juniors
Associate	Assigned matter access, document creation and editing	Draft documents, log time, view assigned matter files
Paralegal	Assigned matter access, limited to document support	Upload documents, manage filing, no billing access
Client Viewer	Read-only access to designated matters	View shared documents, download reports — no editing

Key principle: Roles should reflect job functions, not individual people. If you find yourself creating a role for one specific person, you're doing RBAC wrong — you're creating a permission assignment disguised as a role.³

The NIST RBAC Model

NIST's formal RBAC standard defines four levels of increasing sophistication:²

Level	Name	What It Adds
Core RBAC	Flat RBAC	Users, roles, permissions — the basics
Hierarchical RBAC	Role inheritance	Senior roles inherit junior role permissions (a Partner inherits everything an Associate can do)
Constrained RBAC	Separation of duties	Rules preventing dangerous role combinations (the person who approves invoices cannot also create them)
Symmetric RBAC	Permission-role review	Ability to audit which permissions a role grants and which roles grant a specific permission

Most legal SaaS platforms need at least Hierarchical RBAC. Constrained RBAC becomes critical when your platform handles financial operations — billing, trust accounting, or client fund management — where separation of duties is a regulatory requirement.

Permissions: The Right Granularity

The biggest design challenge in RBAC is permission granularity. Too coarse, and you can't express the access rules your clients need. Too fine, and the system becomes unmanageable.

Too coarse:

can_access_documents: true/false

This grants access to every document in the system — including privileged communications from matters the user isn't assigned to.

Too fine:

can_read_document_12345: true
can_read_document_12346: true
can_read_document_12347: true

This is unmanageable at scale. You'd need thousands of individual permission entries per user.

The right level for legal SaaS:

documents:read    (on matters assigned to the user)
documents:write   (on matters assigned to the user)
documents:delete  (restricted to firm admin and partner roles)
billing:view      (partner and admin roles only)
billing:modify    (admin role only)
users:manage      (admin role only)

Permissions should be resource-type scoped (documents, matters, billing) with CRUD actions (create, read, update, delete), and the application enforces matter-level scoping to ensure users only access matters they're assigned to. The matter-scoping layer is where RBAC meets the specific needs of legal software — we'll explore this in depth in Episode 25 when we cover ethical walls.⁴

API Scopes: Consistent Enforcement

Permissions defined in roles must be enforced at the API layer, not just the UI. The OWASP Authorization Cheat Sheet makes this explicit: "Authorization policies must be enforced at the backend (API) to guarantee security and consistency."⁵

If your UI hides the "Delete" button for paralegals but the API endpoint `/api/documents/:id` accepts DELETE requests from anyone with a valid session, you have a broken access control vulnerability. An attacker — or simply a curious user with browser developer tools — can call the API directly.

The pattern:

Define permissions as API scopes: `documents:read`, `documents:write`, `matters:admin`
When a user authenticates (via SSO from Episode 22), their session or JWT token (from Episode 18) includes the scopes their role grants
Every API endpoint checks the token's scopes before executing — middleware that runs before any business logic
The UI reads the same scopes to show or hide interface elements — but this is cosmetic, not security

Callout: The "hidden button" fallacy. Removing a button from the UI is not access control. It's a UX decision. Access control happens at the API. Every. Single. Request.⁵

Common RBAC Mistakes

1. Role Explosion

Starting with three roles (Admin, Editor, Viewer) and gradually adding "Senior Editor," "Junior Admin," "Billing Viewer," "Matter-Specific Editor" until you have 47 roles and nobody knows which does what. Keep roles aligned to job functions, not individual needs. If a specific user needs an exception, that's an attribute-based decision — covered in Episode 24.

2. Permission Creep

A user gets temporarily promoted or assigned to a special project, receives elevated permissions, and nobody removes them afterwards. Over months, users accumulate permissions far beyond their current role. The fix: regular access reviews. Quarterly audits comparing actual role assignments against current job functions.⁶

3. No Audit Trail

When someone changes a role assignment, is it logged? Can you tell who granted Admin access to a specific user, when, and why? Legal SaaS platforms handling privileged information need immutable audit logs for every permission change — not just for security, but because clients will ask for them during security assessments.

4. Client-Side Enforcement Only

As noted above — hiding UI elements is not enforcement. If your authorisation logic only exists in the frontend, any API call bypasses it entirely.

Implementing RBAC: Middleware Pattern

A clean RBAC implementation uses middleware — code that runs before every API request to check permissions:

Request → Authentication middleware (verify session/JWT)
        → Authorization middleware (check role permissions against required scopes)
        → Business logic (only reached if authorized)

The authorization middleware:

Extracts the user's roles from their session or JWT
Resolves those roles to a set of permissions/scopes
Compares against the permissions required by the specific endpoint
Returns 403 Forbidden if the user lacks the required permission

This centralised pattern ensures that every endpoint is protected by default. New endpoints that forget to specify required permissions should fail closed — deny access — rather than fail open.⁵

Regular Access Reviews

RBAC is not "set and forget." The OWASP Authorization Cheat Sheet recommends periodic reviews:⁵

Quarterly: Review all role assignments against current org charts
On role change: When an employee changes departments or seniority, update roles immediately
On departure: Revoke all roles immediately (automated via SCIM, as covered in Episode 22)
On incident: After any security event, audit whether existing permissions enabled it

For legal SaaS, enterprise clients will ask for access review reports during annual security audits. Building the reporting into your platform — "show me all users with admin access and when it was granted" — is a feature, not overhead.

What's Next

Episode 24 covers ABAC and Policy Engines — when roles aren't enough and you need to make access decisions based on attributes like department, matter type, jurisdiction, or time of day.

Sources & Further Reading

Sources & references

OWASP, A01:2021 — Broken Access Control — #1 in OWASP Top 10, found in 94% of tested applications.
NIST, Role-Based Access Control Project — the NIST RBAC model and ANSI/INCITS 359-2004 standard.
Oso, How to Build a Role-Based Access Control Layer — practical RBAC design guidance.
NIST, The NIST Model for Role-Based Access Control — formal model paper by Sandhu, Ferraiolo, and Kuhn.
OWASP, Authorization Cheat Sheet — backend enforcement, middleware patterns, common mistakes.
Omada, NIST Role-Based Access Control — RBAC implementation best practices and compliance.
SecureLayer7, RBAC Explained: Benefits, Models, and Best Practices — comprehensive RBAC guide.
Wikipedia, Role-Based Access Control — history and formal definitions.
OWASP, A01:2025 — Broken Access Control — continues as #1 in OWASP Top 10 2025 release candidate.
CWE, CWE-1345: OWASP Top Ten 2021 Category A01 — related Common Weakness Enumerations.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 23 — we're moving from authentication into authorisation. RBAC — Role-Based Access Control. Alice, we've spent the last few episodes on proving who someone is. Now we need to figure out what they're allowed to do.

Alice: Right. And this is where legal SaaS gets genuinely hard. Think about the access hierarchy at a typical law firm. You've got firm administrators who manage the platform. Partners who oversee practice groups and billing. Associates who work on specific matters. Paralegals supporting those matters. And sometimes external clients who need read-only access to certain documents. Every one of those people needs different permissions. And if you get it wrong — if a junior associate can see a partner's billing rates, or a client viewer can access a matter they're not party to — you've got a serious problem.

Dan: Mm. And this isn't a niche concern, right? OWASP has something to say about it?

Alice: Broken access control is literally the number one vulnerability in the OWASP Top 10 — we introduced OWASP back in Episode 1. They found some form of broken access control in 94 percent of applications they tested. It's not exotic. It's the most common security failure in web applications.

Dan: Right. So RBAC is the solution?

Alice: RBAC is the foundation. The idea is simple. Instead of assigning individual permissions to each user — which gets completely unmanageable once you have hundreds of users — you create roles. A role is just a named collection of permissions. "Associate" might include permissions to read and edit documents on their assigned matters, log time entries, and view deadlines. "Firm Administrator" includes everything, plus user management and system configuration. You assign users to roles, and they inherit the permissions that role carries.

Dan: Yeah, that's cleaner than managing permissions per person. But how many roles do you actually need?

Alice: For most legal SaaS platforms, five or six covers eighty percent of the need. Firm Admin, Partner, Senior Associate, Associate, Paralegal, Client Viewer. The NIST standard for RBAC — and yes, there is a formal US national standard for this — adds the concept of role hierarchies, where senior roles automatically inherit the permissions of junior roles. A Partner gets everything an Associate can do, plus billing access and matter management.

Dan: Mm. What's the trap? Where does this go wrong?

Alice: The biggest one is role explosion. You start with three roles — Admin, Editor, Viewer. Then someone says "we need a Billing Viewer who can see invoices but not edit them." Then "we need a Senior Editor who can approve document changes." Then "we need a Matter-Specific Admin for just the litigation department." Before you know it, you've got 47 roles and nobody can tell you which permissions each one actually grants. The rule of thumb is: roles should map to job functions, not individual people. If you're creating a role for one specific user's needs, you've left RBAC territory.

Dan: Hmm. What about when someone's permissions should change over time? Like someone gets promoted?

Alice: That's the second big trap — permission creep. An associate gets temporarily promoted to handle a sensitive matter. They get elevated permissions. The matter closes six months later, but nobody removes the extra access. Over time, users accumulate permissions far beyond what they currently need. The fix is regular access reviews — quarterly audits where you compare actual role assignments against current org charts. When we talked about SCIM provisioning in Episode 22, that's the automation side. When someone's role changes in the firm's directory, SCIM can update their role in your application automatically.

Dan: Right. Let me ask about something I see developers get wrong. If you hide a button in the interface — like removing the Delete button for paralegals — is that access control?

Alice: <sigh> No. And this is so common it has a name — the "hidden button" fallacy. Hiding a button in the user interface is a user experience decision. It is not security. If the API endpoint behind that button still accepts requests from anyone with a valid session, any user can call it directly. Open the browser developer tools, find the API URL, and send a DELETE request. If the server processes it, you have broken access control.

Dan: Mm. So where should the check actually happen?

Alice: At the API layer. Every single request. The OWASP Authorisation Cheat Sheet is very explicit about this — authorisation policies must be enforced at the backend to guarantee security and consistency. The pattern is middleware — a layer of code that runs before every API request. It extracts the user's roles from their session or their JWT token, which we covered in Episode 18. It resolves those roles to a set of permissions. And it checks whether the user has the specific permission required by that endpoint. If not, the request gets a 403 Forbidden response before any business logic executes.

Dan: Yeah. And the UI can still read those same permissions to decide what to show?

Alice: Absolutely. The UI reads the user's permissions to show or hide interface elements — that's good UX. But it's cosmetic. The API is the actual gate. Think of it this way: the UI is the velvet rope at a nightclub. The API is the locked door behind it. If someone steps over the rope, they still need to get through the door.

Dan: Mm-hmm. What about scoping? You mentioned that an associate should only access documents on their assigned matters. How does that work with roles?

Alice: This is where legal SaaS goes beyond generic RBAC. A role might say "associates can read and edit documents." But that can't mean all documents in the entire system — it means documents on matters they're assigned to. So you need a second layer of scoping. The role gives you the action permission — "can read documents." The matter assignment gives you the resource scope — "on these specific matters." Every database query needs to include both checks. We'll go much deeper on this in Episode 25 when we cover ethical walls and matter-scoped access.

Dan: Right. One more question — API scopes. How do those tie into roles?

Alice: API scopes are the technical encoding of permissions. When a user logs in and gets a session or a JWT token, that token contains a list of scopes — like documents:read, documents:write, billing:view, users:manage. Those scopes are derived from the user's role. The API middleware checks the token's scopes against what the endpoint requires. It creates a clean, consistent enforcement chain: user gets assigned a role, role maps to scopes, scopes travel in the token, API checks scopes on every request.

Dan: Mm. And for anyone building this right now — the key takeaway?

Alice: Three things. First, keep your role model simple — five or six roles mapped to job functions, not individual people. Second, enforce permissions at the API, never just the UI. Third, build access review reporting into your platform from the start, because enterprise law firm clients will ask for it during every security audit. "Show me every user with admin access and when it was granted" should be a one-click report, not a database spelunking exercise.

Dan: Next episode — ABAC and Policy Engines. When roles aren't enough and you need to make access decisions based on attributes like department, matter type, or time of day.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.