Episode 24 · Module 6 · Authorization & Access Control

ABAC and Policy Engines

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

8:37 8:37

In Episode 23, we built a role-based access control model with five or six roles: Firm Admin, Partner, Associate, Paralegal, Client Viewer. That covers 80% of access decisions. This episode is about the other 20% — the decisions where a role alone doesn't carry enough information. Consider this scenario: an associate in the M&A practice group needs access to M&A matter documents during business hours from the firm's network. RBAC can tell you they're an associate. It cannot tell you they're in M&A, that the document is tagged as M&A, that it's currently 2pm on a Tuesday, or that they're connecting from the office VPN. For those decisions, you need Attribute-Based Access Control — ABAC.

Today’s Lesson

Security for Legal SaaS — Episode 24: ABAC and Policy Engines

When Roles Are Not Enough

Consider this scenario: an associate in the M&A practice group needs access to M&A matter documents during business hours from the firm's network. RBAC can tell you they're an associate. It cannot tell you they're in M&A, that the document is tagged as M&A, that it's currently 2pm on a Tuesday, or that they're connecting from the office VPN. For those decisions, you need Attribute-Based Access Control — ABAC.

What Is ABAC?

ABAC makes access decisions based on attributes — properties of the user, the resource, the action, and the environment. Instead of a static role-to-permission mapping, ABAC evaluates a policy that considers multiple attributes at decision time.¹

The four attribute categories:

Category	Examples in Legal SaaS
Subject attributes	User's role, department, practice group, seniority, bar admission status
Resource attributes	Matter type (litigation, M&A, IP), confidentiality level, client name, jurisdiction
Action attributes	Read, write, delete, export, share externally
Environment attributes	Time of day, network location (office VPN vs. public wifi), device compliance status

An ABAC policy combines these attributes into rules:

Allow if subject.department = "M&A" AND resource.matter_type = "M&A" AND action = "read" AND environment.time is within business_hours

This is fundamentally more expressive than RBAC. A single ABAC policy can encode what would require dozens of purpose-built roles.²

RBAC + ABAC: The Practical Approach

Pure ABAC — replacing all roles with attribute policies — is theoretically elegant but operationally complex. Most real-world systems use a hybrid approach:³

RBAC for broad strokes: Roles define the general permission level (Admin, Associate, Viewer)
ABAC for fine-grained decisions: Attributes refine access within a role (which matters, which document types, under what conditions)

In a legal SaaS platform, this looks like:

RBAC determines: "Associates can access matter documents"
ABAC refines: "Associates in the litigation department can access litigation matter documents marked Confidential, during business hours, from managed devices"

The role gets the user through the first gate. The attributes decide exactly which resources they can touch and under what conditions.

Policy Engines: Externalising Access Decisions

Hardcoding access rules in application code — `if (user.role === 'admin' || (user.role === 'associate' && matter.department === user.department))` — works for simple cases but becomes unmaintainable as rules multiply. Policy engines solve this by externalising access decisions into a dedicated service that your application queries at runtime.⁴

Open Policy Agent (OPA)

Open Policy Agent is the most widely adopted general-purpose policy engine, donated to the Cloud Native Computing Foundation (CNCF) and graduated in 2021.⁵ Policies are written in Rego, a declarative query language:

rego

allow if {
    input.user.role == "associate"
    input.user.department == input.resource.practice_group
    input.action == "read"
}

OPA runs as a sidecar service alongside your application. When a user requests access to a resource, your application sends the relevant attributes to OPA, and OPA returns an allow/deny decision. The application never evaluates the policy itself — it delegates entirely to OPA.⁵

Strengths: Language-agnostic (works with any backend), extensive ecosystem, Kubernetes-native, well-tested in production at large scale.

Tradeoffs: Rego has a learning curve. Policies are powerful but can become complex. Performance requires careful policy design at high query volumes.

AWS Cedar

Cedar is AWS's purpose-built authorisation policy language and engine, open-sourced in 2023 and used in production by Amazon Verified Permissions.⁶ Cedar was explicitly designed for application-level authorisation — it's more specialised than OPA's general-purpose approach:

cedar

permit(
    principal in Role::"associate",
    action == Action::"readDocument",
    resource in MatterGroup::"litigation"
) when {
    principal.department == resource.practiceGroup
};

Strengths: Formal verification — Cedar's type system can mathematically prove that certain policy configurations are correct. Designed specifically for RBAC + ABAC hybrid models. Simpler syntax than Rego for authorisation-specific use cases.

Tradeoffs: Narrower scope than OPA (authorisation only, not general policy). Newer ecosystem with fewer community integrations.

Google Zanzibar / OpenFGA

Zanzibar is Google's internal authorisation system, handling trillions of access checks per second for Google Drive, YouTube, and Google Cloud.⁷ OpenFGA is the open-source implementation. Unlike OPA and Cedar, Zanzibar uses a relationship-based model — access is determined by the relationships between users and resources (e.g., "Alice is an editor of Document X" or "Alice is a member of Team Y which owns Matter Z").⁸

Strengths: Exceptional performance at scale. Natural fit for document sharing and collaboration models. Strong consistency guarantees.

Tradeoffs: The relationship model is different from traditional RBAC/ABAC thinking — requires rethinking how you model access.

Comparison summary from AWS and Teleport security benchmarks: OPA is best for general-purpose policy across infrastructure and applications. Cedar excels at application-level authorisation with formal verification. Zanzibar/OpenFGA is optimal for relationship-heavy models like document sharing.⁹

Performance: Policy Evaluation at Scale

Legal SaaS platforms evaluate authorisation decisions on every API request — potentially thousands per second during peak usage. Policy engine performance is a real concern:¹⁰

Consideration	Guidance
Caching	Cache policy decisions for identical inputs (same user, same resource, same action). Invalidate on role changes
Data locality	Keep frequently-used attributes (user role, matter assignments) in the policy engine's data store, not fetched per-request from a remote database
Policy complexity	Simpler policies evaluate faster. Avoid deeply nested conditions or external data calls in hot paths
Bulk evaluation	When loading a matter list, evaluate access for all matters in one batch call rather than one-per-matter

A well-configured OPA instance can evaluate policies in sub-millisecond time for typical authorisation queries. Cedar was benchmarked by AWS at similar performance. The overhead of a policy engine call is negligible compared to a database query.⁵⁶

Legal Context: Where ABAC Shines

Several legal SaaS scenarios specifically require attribute-based policies:

Matter-based access: An associate should only access matters they're assigned to. The assignment is an attribute of the relationship between user and matter — not a role.

Jurisdiction restrictions: A document produced under Australian privacy law may require that only users admitted to practice in Australia (a subject attribute) can access it.

Time-limited access: A contract review team gets access to due diligence documents for 90 days. After the deal closes, access automatically expires based on an environment attribute (current date vs. access expiry).

Confidentiality tiers: Documents classified as "Attorney Eyes Only" require both the correct role (attorney) and the correct matter assignment. Documents at "Highly Confidential" require an additional approval attribute.

Export controls: Downloading or sharing documents externally may require approval from a supervising partner — an action that changes the user's attributes for that specific resource.

The AuthZEN Standard

The industry is converging on standardised interfaces for policy engines. AuthZEN, an OpenID Foundation working group, is developing a standard API for authorisation — a single interface that works regardless of whether the backend is OPA, Cedar, OpenFGA, or a custom engine.¹¹ For legal SaaS builders, this means you can adopt a policy engine today without permanent vendor lock-in.

What's Next

Episode 25 covers Ethical Walls and Matter-Scoped Access — the legal profession's specific access control requirement where two partners in the same firm may be on opposite sides of the same deal, and your software must enforce the barrier.

Sources & Further Reading

Sources & references

NIST, SP 800-162: Guide to Attribute Based Access Control (ABAC) — the NIST ABAC standard.
CNCF, Love, Hate, and Policy Languages: An Introduction to Decision-Making Engines — comparison of policy approaches (May 2024).
Oso, OPA vs Cedar vs Zanzibar: 2025 Policy Engine Guide — comparative analysis of leading policy engines.
Permit.io, Policy Engines: Open Policy Agent vs AWS Cedar vs Google Zanzibar — architectural comparison.
Open Policy Agent, OPA Documentation — official OPA documentation and Rego language reference.
AWS, Cedar Policy Language — Cedar documentation and formal verification details.
Google Research, Zanzibar: Google's Consistent, Global Authorization System — original Zanzibar paper (2019).
OpenFGA, OpenFGA Documentation — open-source Zanzibar implementation.
Teleport, Security Benchmarking Authorization Policy Engines — comparative security analysis of Rego, Cedar, and OpenFGA.
Auth0, Understanding ReBAC and ABAC Through OpenFGA and Cedar — relationship-based vs. attribute-based models.
Nordic APIs, AuthZEN: A New Standard for Fine-Grained Authorization — the emerging authorisation API standard.

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

Dan: And I'm Dan. Episode 24 — ABAC and policy engines. Alice, last episode we built a role-based access control model with about five or six roles. You said that covers 80 percent of access decisions. Today is about the other 20 percent?

Alice: Exactly. Here's the scenario that breaks pure RBAC. You have an associate in the M&A practice group. They should be able to read M&A matter documents — but not litigation documents, even though they have the same "Associate" role as someone in the litigation group. RBAC says "associates can read documents." But it can't say "associates can read documents in their own practice group, during business hours, from a managed device." That's where ABAC comes in — Attribute-Based Access Control.

Dan: Mm. So instead of just checking the role, you're checking a bunch of properties?

Alice: Right. ABAC evaluates four categories of attributes when making an access decision. Subject attributes — that's about the user. Their role, their department, their practice group, their seniority. Resource attributes — that's about the thing they're trying to access. Is this document tagged as M&A or litigation? What confidentiality tier is it? Action attributes — are they trying to read it, edit it, download it, share it externally? And environment attributes — what time is it, are they on the office network or public wifi, is their device managed by the firm's IT?

Dan: Right. So an ABAC policy might say something like: allow access if the user's department matches the document's practice group, the action is read, and they're on the VPN.

Alice: Exactly. And the practical approach is to combine RBAC and ABAC. Use roles for the broad strokes — the role gets you through the first gate. Then use attributes for the fine-grained decisions within that role. The role says "you're an associate, you can access matter documents." The attributes say "specifically, you can access M&A documents tagged up to Confidential level, from a managed device."

Dan: Hmm. But where do these policies actually live? You're not hardcoding all of this in your application, right?

Alice: No — and that's where policy engines come in. A policy engine is a separate service that your application queries whenever it needs to make an access decision. Your application sends the attributes — who's asking, what they want, under what conditions — and the engine evaluates the policy and returns allow or deny. The rules live outside your application code, which means you can update policies without redeploying your application.

Dan: Yeah. So what are the main options?

Alice: Three big ones. First is Open Policy Agent — OPA. It's the most widely adopted, it's a graduated project in the Cloud Native Computing Foundation, and it's been in production at large scale since about 2018. You write policies in a language called Rego. OPA is general-purpose — you can use it for authorisation, but also for Kubernetes admission control, API gateway policies, infrastructure compliance. It's very powerful.

Dan: Mm-hmm. And the second?

Alice: Cedar — developed by AWS and open-sourced in 2023. Cedar is purpose-built for application-level authorisation. It's more specialised than OPA. The syntax is more readable for authorisation rules, and it has a key feature that lawyers should appreciate — formal verification. Cedar's type system can mathematically prove that certain policy configurations are correct. You can verify, before deploying, that no combination of attributes will accidentally grant admin access to a regular user.

Dan: That's interesting — formal proof of correctness. What's the third?

Alice: Google Zanzibar, or more practically its open-source implementation called OpenFGA. Zanzibar is the system Google uses internally — it handles access checks for Google Drive, YouTube, Google Cloud. The model is fundamentally different. Instead of evaluating attributes, it checks relationships. "Alice is an editor of Document X." "Alice is a member of Team Y, and Team Y owns Matter Z." It's incredibly fast at scale because relationship lookups are simpler than arbitrary policy evaluation.

Dan: Mm. Which one should someone building legal SaaS pick?

Alice: It depends on your access model. If your primary pattern is "users belong to practice groups and need access to matters within those groups" — that's a relationship model, and Zanzibar or OpenFGA is a natural fit. If you need complex conditional logic — time-based access, jurisdiction restrictions, confidentiality tiers — OPA or Cedar gives you more expressive power. For most legal SaaS platforms, I'd lean toward Cedar for application-level authorisation. The formal verification alone is worth the trade-off of a smaller ecosystem.

Dan: Right. Let me ask about performance. If every API request has to call out to a policy engine, doesn't that add latency?

Alice: <sigh> This is one of those concerns that sounds reasonable but doesn't hold up in practice. A well-configured OPA instance evaluates typical authorisation queries in under a millisecond. Cedar benchmarks similarly. Compare that to the 5 to 50 milliseconds your database query takes, and the policy evaluation is basically free. The key is keeping frequently-used attributes — user roles, matter assignments — loaded in the policy engine's local data store, so you're not making network calls to look them up on every request.

Dan: Mm. What about caching?

Alice: You can cache decisions for identical inputs — same user, same resource, same action. Invalidate the cache when roles change or matter assignments update. But be careful with time-based policies. If access expires at 5pm, the cache needs to respect that. The standard pattern is a short TTL — a few seconds — for time-sensitive policies, and longer TTLs for stable ones like role membership.

Dan: Yeah. Give me a real legal scenario where ABAC makes a difference that pure RBAC can't handle.

Alice: Deal room access. A corporate M&A team gets access to due diligence documents for 90 days. After the deal closes, access automatically expires. RBAC can give them the "deal team member" role. But only an environment attribute — current date compared to the deal's expiry date — can automatically revoke access when the window closes. Without ABAC, someone has to remember to manually remove access after every deal. With ABAC, the policy handles it.

Dan: Mm. Another one?

Alice: Document export controls. Reading a document internally is one thing. Downloading it or emailing it outside the firm is another. ABAC can require a different approval attribute for export actions. The user has permission to read — but to download, they need an additional approval flag from the supervising partner. Same user, same document, different action — different policy outcome.

Dan: Right. Quick summary — RBAC for the broad strokes, ABAC for the fine grain. Externalise your policies into an engine like OPA, Cedar, or OpenFGA instead of hardcoding them.

Alice: And one more thing — the industry is converging on a standard API for authorisation called AuthZEN, from the OpenID Foundation. It means you can pick a policy engine today and swap it later without rewriting your application. The interface stays the same.

Dan: Next episode — Ethical Walls and Matter-Scoped Access. When two partners in the same firm are on opposite sides of the same deal.

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.