Policy-Based Access Control (PBAC): authorization as explicit policy

Seventeen copies of one rule

When compliance changes the support access rule, so that agents may see a customer’s account only while they have an open ticket for that customer, David is asked how long the change will take. He searches the codebase for the existing check and finds it seventeen times, across six services. Three of the copies don’t match the others: one never checked the region, one applied the check to reading accounts but not to exporting them, and one was a two-year-old version that someone had pasted in and never updated. Nobody can say with confidence what the system’s access rule actually is today, and changing it means editing seventeen places and hoping they all end up the same.

The ABAC article ended with a pseudo-policy, a small block of permit if clauses over attributes. That block raised a question it left open: where does the policy actually live, and who evaluates it? Historically the answer has been grim. Authorization logic ends up scattered through application code as thousands of if statements, buried in controllers and middleware, duplicated inconsistently across services, invisible to auditors, and changeable only by shipping new code. Policy-based access control (PBAC) answers that problem by making the policy an explicit artifact in its own right, written in a formal language, kept in one place, and evaluated by a dedicated engine.

PBAC and ABAC are close cousins, and people often use the terms interchangeably. The distinction worth keeping is one of emphasis. ABAC is about the inputs to a decision, the attributes. PBAC is about how the decision logic itself is expressed and run, as declarative, externalized policy, separate from the code that enforces it. Almost every PBAC system is attribute-based inside, so the cleanest way to think about it is ABAC put into operation: take the attribute logic ABAC described and raise it into a governed policy document and a real decision engine you can version, test, and audit.

The idea that policy should be separate from mechanism is old, but PBAC took shape around XACML, the eXtensible Access Control Markup Language that OASIS standardized in the mid-2000s. XACML did two lasting things. It defined a reference architecture, the PEP, PDP, PIP, and PAP that the XACML architecture article covers, which cleanly separated deciding from enforcing from administering, and it gave policy a formal structure of policy sets, policies, and rules with a request and response protocol. Its XML was verbose and its adoption uneven, but its architecture won completely: every modern authorization engine, whatever its language, is recognizably an implementation of the pattern XACML named. The 2010s brought lighter, developer-friendly successors, Open Policy Agent’s Rego and later AWS’s Cedar, that kept XACML’s separation of concerns and dropped the XML.

The core move: separate the decision from the code

PBAC’s defining idea is a separation that sounds simple and changes everything: the code that enforces a decision shouldn’t be the code that makes it. An application should ask whether this subject may perform this action on this resource under these conditions, and enforce the answer, while the logic that produces the answer lives outside, in policy. This is externalized authorization, and its two halves already have names from the Zero Trust article: the policy enforcement point (PEP), the code in the app that asks and enforces, and the policy decision point (PDP), the engine that evaluates policy and answers.

Once you make that split, authorization stops being a property of each application and becomes a shared service. Ten microservices no longer each reinvent “who can see this order”; they all ask the same PDP, which evaluates the same policy. Change the rule once and every service changes together, with no redeployment. That one property, one policy and many enforcers, is why large organizations invest in PBAC.

It’s worth seeing why the inline alternative fails so reliably, because the failure isn’t laziness but structure. When each service owns its checks, the same rule gets implemented slightly differently in each, exactly as David found: one team forgets the region condition, another applies it to reads but not exports, a third copies an old version. There’s no single place to read the access rules, so audits turn into archaeology and every change risks missing a copy. Externalization doesn’t just tidy this up; it makes the drift impossible, because there’s only one copy to change.

flowchart LR
  accTitle: Externalized authorization with a shared policy decision point
  accDescr: Two applications, App A and App B, each contain a Policy Enforcement Point. Both enforcement points send authorization queries to a single shared Policy Decision Point in the center. The decision point loads a formal policy from a policy store and fetches data such as subject attributes and resource attributes from data sources. It evaluates the policy against that data and returns a permit or deny decision to whichever enforcement point asked. The diagram emphasizes that one policy serves many applications.
  A[App A<br/>PEP] -->|can subject do action?| PDP{Policy Decision Point}
  B[App B<br/>PEP] -->|can subject do action?| PDP
  POL[(Formal policy)] --> PDP
  DATA[(Subject / resource data)] --> PDP
  PDP -->|permit / deny| A
  PDP -->|permit / deny| B

Why a formal language matters

PBAC’s second pillar is that policy is written in a formal, declarative language rather than general-purpose code. That isn’t pedantry; it unlocks concrete capabilities. A policy in Rego, the language of Open Policy Agent, in Cedar, AWS’s language, or in XACML can be versioned in source control like any artifact, unit-tested with example requests and expected decisions, reviewed in a pull request by security and application owners together, and in some languages analyzed for properties like “can an unauthenticated user reach any resource?” None of that is reliably possible when the rule is an if buried three calls deep in a service.

Declarative also means the policy states what’s allowed rather than how to check it, so it reads closer to the requirement. Here’s the support rule as Rego:

package authz
 
default allow = false
 
allow if {
  input.action == "read"
  input.subject.role == "support_agent"
  input.subject.region == input.resource.region
  input.resource.type == "customer_account"
  ticket_open
}
 
ticket_open if {
  some t in data.tickets
  t.agent == input.subject.id
  t.customer == input.resource.customer_id
  t.status == "open"
}

That’s the rule the ABAC article wrote as pseudocode, now an executable, testable artifact. A reviewer can read it, it lives in one file, and changing the ticket condition doesn’t touch a single application. That’s the rule David now changes once instead of seventeen times. Imperative authorization code answers “which checks does this endpoint run?”, a question with a different answer at every endpoint, which is how drift happens. Declarative policy answers “what’s the rule?”, with one answer everywhere. When authorization is declarative, you can ask an auditor’s questions of the policy directly instead of reverse-engineering them from code, and that’s often the biggest practical gain from adopting PBAC.

More than permit and deny

One thing that separates mature PBAC from a plain yes-or-no check is that a decision can carry more than a verdict. XACML formalized two extras that good authorization systems still use. An obligation is something the enforcement point must do when it acts on a decision: “permit, but log this access to the audit trail,” or “deny, and notify the security team.” An advice is a softer, optional recommendation the PEP may follow: “permit, and show a data-handling notice.” The decision becomes a small set of instructions rather than a bare verdict.

Real authorization is rarely a bare gate. “You may export this report, but the export must be watermarked and logged” is one decision with an obligation attached, and expressing it in one policy keeps the security requirement tied to the access instead of scattered as separate code someone will forget. Obligations are how PBAC expresses “allowed, with conditions,” step-up authentication, mandatory logging, a prompt for the reason for access, a grant that expires, in the same place the allow and deny live.

How the engine gets its data

A policy does nothing without data, the attributes and relationships it tests, and there are two ways to get that data to the engine. In the pull model, the PDP fetches what it needs at decision time, calling the identity provider, a resource service, or a risk feed as it evaluates. The data is as fresh as it can be, but every decision gains latency and outside dependencies, and a slow data source makes authorization slow. In the push model, the data is delivered to the engine in advance, bundled with the policy or streamed as it changes, so evaluation is local and fast, at the cost of the data being only as fresh as the last update.

High-performance PBAC mostly leans on push. Open Policy Agent, for instance, evaluates against data loaded into the engine rather than calling out mid-decision, which is what lets it decide in microseconds. It’s the same trade between freshness and latency you met with sessions, token revocation, and attribute caching, a recurring theme in identity because every authorization system has to decide how current its data must be and what keeping it current costs.

The policy lifecycle

Treating policy as an artifact means it gets a lifecycle, much like code, and naming the stages is how you stop it decaying into the sprawl it was meant to cure. Authoring writes the policy, close to the requirement and owned by someone accountable. Testing runs it against a suite of representative requests with known expected decisions, so a change to one rule can’t silently break another; it’s the single most important discipline in PBAC and the reason policy as code exists. Deployment distributes the policy to the decision engines, versioned so you can roll back. Evaluation is runtime, the engine answering queries against the current policy and data. And review periodically re-examines the policy for rules that are obsolete, overlapping, or too broad, the way access certification prunes roles.

XACML calls the tooling where policies are written and managed the policy administration point (PAP). The point here is that PBAC isn’t only a runtime mechanism; it’s a practice, and the practice decides whether externalized policy stays clean. A policy engine with no test suite and no review rhythm becomes an opaque tangle just like unmanaged application code; it has only moved the mess.

Making policy an explicit artifact also means you can analyze it, not just run it. Because the policy is a document rather than code spread everywhere, tools can ask questions of the whole thing at once. Conflict analysis finds rules that overlap and disagree, revealing where the combining algorithm is quietly deciding something you didn’t intend. Gap analysis finds requests no rule covers, which then fall through to the default; a default-deny gap is a broken feature and a default-permit gap is a security hole. Coverage checks confirm that every resource type and action the system exposes is governed by some rule, catching the endpoint someone forgot to protect. Some policy languages go further and support formal reasoning, proving properties such as “no unauthenticated principal can reach any resource tagged confidential” across the entire policy instead of testing a handful of examples. That’s impossible when authorization is scattered imperative code, because you can’t analyze what you can’t see in one place.

Who owns the policy?

The hardest PBAC question isn’t technical but organizational: who writes and owns policy? Centralizing authorization creates one artifact that governs everything, which raises the stakes of every change and forces a decision the scattered-code era let you avoid. Hand all policy to a central security team and you get consistency but a bottleneck, because that team blocks every feature that touches access. Let each application team write its own policy freely and you risk the drift and overly broad self-grants PBAC was meant to prevent. The workable middle is federated with guardrails: application teams write policy for their own resources, a central team owns the shared base policy and reviews changes, and automated tests and analysis enforce rules nobody may break. Getting this operating model right matters at least as much as choosing a policy engine, and it’s where PBAC programs most often succeed or quietly fail.

The anatomy of a policy

The vocabulary of how policies are structured recurs across every engine, even when the syntax differs. The smallest unit is a rule, with a target saying which requests it applies to (“actions on customer accounts”), an optional condition for the finer test (“the region matches”), and an effect, permit or deny. Rules group into a policy, a coherent set of rules about one area with its own combining algorithm for internal disagreements. Policies group into policy sets, which can nest, each layer with its own combining algorithm. A request is evaluated from the top down through this tree, and the combining algorithms at each level fold the partial decisions into one final permit or deny.

That hierarchy isn’t bureaucracy; it’s how a large policy stays understandable. Organizing rules into policies by resource type, and policies into sets by domain, is PBAC’s equivalent of splitting a big program into modules, and it’s the difference between a policy you can reason about and the policy explosion that mirrors role explosion.

PBAC as the umbrella

There’s a helpful way to see PBAC alongside everything before it: as the umbrella under which the other models can be expressed. A policy can encode a role check, subject.role == "admin", which is RBAC inside a policy. It can compare attributes, subject.region == resource.region, which is ABAC inside a policy. It can encode label rules like MAC, or relationship checks, as the next article shows. PBAC doesn’t compete with RBAC and ABAC so much as provide the vehicle for expressing and running them uniformly, in one governed place, with one engine.

That’s why so many real systems are described as policy-based even when their rules are mostly about roles and attributes: what defines PBAC isn’t what the rules test but that the rules are explicit, externalized, formal policy. It also dissolves a lot of pointless “RBAC versus ABAC versus PBAC” debate. They aren’t three competitors on one axis. Two describe what a decision is based on; the third describes how the decision logic is expressed and run. You can, and usually should, do RBAC and ABAC inside a PBAC framework, which is what the hybrid systems of the last two articles turn out to be.

PBAC in practice

The model is concrete and widely deployed. Open Policy Agent (OPA) with its Rego language is the de facto open standard for externalized policy, used to authorize Kubernetes admission, microservice API calls, and CI/CD actions from one engine. AWS Cedar and Amazon Verified Permissions offer a purpose-built authorization language and a managed PDP. XACML is the older XML-based OASIS standard that pioneered the PEP, PDP, and PAP architecture and still runs in many enterprise and government systems. And a wave of developer-focused services, the fine-grained authorization engines, package PBAC ideas behind friendlier APIs. Whether the language is Rego, Cedar, or XACML, and whether the engine is a sidecar, a library, or a managed service, the shape is the same: a PEP asks, a PDP decides against externalized policy, and data flows in from authoritative sources.

There’s a clear industry direction here: authorization is following the path configuration and infrastructure already took, from custom code toward managed, declarative services. Just as teams stopped writing deployment scripts by hand once Terraform and Kubernetes existed, they increasingly decline to hand-roll authorization once OPA, Cedar, and hosted permission services exist. You’ll hear this called “authorization as a platform capability,” something a service consumes rather than reimplements, and PBAC is its precondition: you can’t offer authorization as a shared service until the policy is an explicit, externalized artifact.

What PBAC costs

PBAC’s benefits are real, and so are its costs. There’s a learning curve, because policy languages like Rego are powerful but unfamiliar, and a badly written policy is a security bug. There’s a runtime dependency: every request now involves a decision call, which has to be fast and highly available, because a slow PDP taxes every action and a PDP that’s down can stop the whole system unless its failure mode is designed deliberately. That failure mode is itself a security decision. Should the PEP fail closed, denying when the PDP can’t be reached and favoring safety at the cost of an outage, or fail open, allowing and favoring availability at the cost of security? For sensitive actions the answer is almost always fail closed, which is why real deployments push policy and data out to the enforcement point: a local, embedded decision can’t be cut off by a network partition. The decentralized authorization article is largely about this. There’s the data problem, identical to ABAC’s: decisions are only as good as the attributes and relationships the engine receives. And there’s governance, with real organizational weight: who may write policy, who reviews it, and how do you stop an application team from quietly writing itself an overly broad rule?

Moving authorization into a central policy doesn’t automatically make it good; it makes it central, which is only an improvement if the policy is disciplined. An externalized policy with no tests, no owner, and a thousand ad hoc rules is arguably worse than scattered code, because now one tangled artifact governs everything and nobody dares change it. The tool centralizes authorization; the discipline is what makes centralizing it a win.

One policy, two services, and a rollback

Picture the cashback fintech the domain’s final case study develops. Its customer app and its internal support console both need to answer “may this actor view this account?” Without PBAC, each embeds its own logic, and the day the rule changes, someone has to find and edit it in two codebases and hope they match. With PBAC, both apps hold only a PEP, both ask the same PDP, and the rule lives in one Rego policy. Changing it is a reviewed, tested pull request to one file, deployed once, and both services obey identically a second later.

Because the policy is versioned, the change can also be undone. If the new open-ticket rule breaks a legitimate workflow, you roll the policy back to the previous version, one revert deployed in seconds, both services restored, instead of rushing to redeploy two applications. Authorization changes are exactly the kind that occasionally go wrong in production, and having them behave like any other versioned artifact turns a potential incident into a non-event. Then a new fraud-review tool is built, and it simply calls the PDP and inherits the same account rules for free. That compounding leverage, every new service getting consistent authorization by asking instead of rebuilding, is PBAC’s practical reward.

There’s a limit even here. The rule still leaned on a relationship, the ticket assigned to this agent for this customer. Expressing access mainly as a web of relationships between entities is awkward even in a good policy language, and that’s the seam the next model was built to own.

Recap

Policy-based access control makes the authorization decision an explicit, externalized, governed artifact. Policy leaves the code: authorization logic moves out of scattered if statements into explicit policy evaluated by a dedicated engine, split into a policy enforcement point that asks and enforces and a policy decision point that decides. One policy serves many enforcers, so a shared PDP lets many applications obey the same rules, changed once without redeploying every service. A formal language brings rigor, making policy versionable, testable, reviewable, and analyzable, which scattered code never reliably is. PBAC is the umbrella: roles, attributes, labels, and relationships can all be expressed as policy, and what defines it is that the policy is explicit, external, and governed. And discipline is the price: a policy language, a runtime dependency, data quality, and governance are real costs, and without tests, ownership, and review, a central policy only relocates the mess.

Three questions to test yourself

1. Explain the difference between a policy enforcement point and a policy decision point, and describe what becomes possible once you separate them that isn’t possible when authorization is inline if statements in each service.
2. A colleague says, “PBAC and ABAC are the same thing.” Give the most useful distinction between them, and explain why almost every PBAC system is attribute-based underneath, using the idea of PBAC as ABAC put into operation.
3. Your team moves authorization into a single Rego policy, but six months later nobody wants to touch it. Diagnose which parts of the policy lifecycle were skipped, and name three practices that would have kept the central policy maintainable.

Hands-on exercises

1. Write and test a policy. Using the Open Policy Agent playground or the opa command-line tool, write a small Rego policy that allows an action only when a subject attribute matches a resource attribute. Then write two test inputs, one that should permit and one that should deny, and run them. That’s the core PBAC loop: policy plus tests.
2. Find the PEP and PDP in a system you use. For any platform with externalized authorization, such as Kubernetes with OPA Gatekeeper, a service mesh, or a cloud authorization service, identify what plays the PEP and what plays the PDP. Note where the policy is stored and how it’s updated.
3. Refactor an inline check on paper. Take one real authorization if statement from code you know and rewrite it as an externalized policy rule. List what you gained (versioning, testing, one source of truth) and what new dependency you introduced (a decision call on the request path), and decide whether the trade is worth it in that case.