The XACML Model: PEP, PDP, PIP & PAP

From “what to decide” to “how to build the decider”

The whole previous module answered one question: what should an access decision be based on? Owners, labels, roles, attributes, policies, relationships — six answers, one axis. This new module turns ninety degrees to a different question: however you decide, how do you actually build the machine that decides? What are its parts, who talks to whom, and where does policy live? The answer that the entire industry converged on has a name — the XACML reference architecture — and once you can see its four components in any system, every authorization product you meet stops being mysterious and becomes a variation on one familiar blueprint.

XACML stands for eXtensible Access Control Markup Language, an OASIS standard from the mid-2000s. Here is the twist that makes it worth a whole article: XACML’s language — its verbose XML syntax — is today largely legacy, displaced by friendlier successors. But XACML’s architecture — the way it splits an authorization system into four cooperating roles — won completely. Open Policy Agent, AWS Cedar, Amazon Verified Permissions, Zanzibar-style engines, your cloud’s IAM: peer inside any of them and you find the same four parts doing the same four jobs. So we study XACML not to write its XML, but because it gave us the vocabulary and the shape that all modern authorization shares. Learn it once, and you can read them all.

Because these four components have off-putting acronyms — PEP, PDP, PIP, PAP — we are going to meet them first as people, through an analogy, and only then attach the technical names. That is the fastest path to never confusing them again.

The analogy: getting into a members-only venue

Imagine Sara wants to enter an exclusive members’ club. Four different people, with four different jobs, together determine whether she gets in — and crucially, no single person does more than one job. That separation is the architecture.

Meet the cast:

• The Doorkeeper stands at the entrance. When Sara arrives, the Doorkeeper stops her, and — depending on the answer he gets — either steps aside to let her in or blocks her. Notice what the Doorkeeper does not do: he does not know the membership rules, does not look anyone up, and does not decide. He only asks and enforces. He is the Policy Enforcement Point (PEP).
• The Manager, in a back office, is the one who actually decides. The Doorkeeper radios “there’s a Sara here — is she allowed in?”, and the Manager, consulting the club’s rules, answers “permit” or “deny.” The Manager holds the logic, not the door. She is the Policy Decision Point (PDP).
• The Records Clerk keeps the files. To decide, the Manager often needs facts she does not have in hand: Is Sara’s membership current? What tier is she? Is she over 18? She asks the Clerk, who looks these up and reports back. The Clerk supplies information, nothing more. He is the Policy Information Point (PIP).
• The Owner wrote the house rules — “gold members enter any time, silver members before 10pm, no one under 18” — and handed them to the Manager before the club even opened tonight. The Owner authors the rules, ahead of time, and is nowhere near the door during Sara’s arrival. She is the Policy Administration Point (PAP).

That is the entire model. Four roles, cleanly separated: one enforces, one decides, one informs, one authors. Every confusing acronym below is just one of these four people. Hold the venue in your head and you will never mix them up.

The four components, precisely

Now we can be exact. Here is each component, its analogy, its single responsibility, and — just as important for avoiding confusion — what it deliberately does not do.

A few refinements complete the picture. Between the PEP and the PDP there is usually a context handler — the messenger who translates the application’s request into the PDP’s expected format, gathers the attributes the PDP asks for by calling the PIPs, and carries the decision back. Think of it as the Manager’s assistant who runs between the office, the door, and the filing room so the Manager can focus on deciding. XACML also names a Policy Retrieval Point (PRP), the store the PDP loads policies from — the shelf where the Owner’s rulebook sits. You will not always see these two called out explicitly, but they are implied wherever the four main roles appear.

Watching a request flow through the machine

Roles are clearest in motion. Follow one request — Sara asks to enter — as it travels through all four components and comes back as a decision. The sequence below is exactly what happens inside a XACML-style system, with the venue labels alongside so the two stay welded together.

sequenceDiagram
  accTitle: How an access request flows through the XACML reference architecture
  accDescr: The diagram shows the ordered message flow for a single authorization request. First, the Policy Administration Point publishes policies to the decision engine ahead of time, marked as setup. Then Sara sends an access request to the Policy Enforcement Point. The enforcement point forwards the request to the context handler, which asks the Policy Decision Point for a decision. The decision point loads the applicable policy and, needing more facts, requests attributes through the context handler, which queries the Policy Information Point and returns subject, resource, and environment attributes. The decision point evaluates the policy against the request and attributes, then returns permit or deny to the context handler, which passes it to the enforcement point. Finally the enforcement point either allows or blocks Sara's access. The administration step is separated in time from the live request flow.
  participant U as Sara
  participant PEP as PEP (Doorkeeper)
  participant CH as Context handler
  participant PDP as PDP (Manager)
  participant PIP as PIP (Clerk)
  participant PAP as PAP (Owner)
  PAP-->>PDP: publish policies (setup, before the request)
  U->>PEP: request access
  PEP->>CH: forward request
  CH->>PDP: decide?
  PDP->>CH: need attributes
  CH->>PIP: fetch subject / resource / environment
  PIP-->>CH: attributes
  CH-->>PDP: attributes
  PDP->>PDP: evaluate policy
  PDP-->>CH: permit / deny
  CH-->>PEP: permit / deny
  PEP-->>U: allow or block

Read it as a story. Ahead of time, the Owner (PAP) publishes the rules to the Manager (PDP) — this is the dashed setup step, and it is the only part that does not happen during Sara’s request. Then Sara asks the Doorkeeper (PEP) to enter. The Doorkeeper does not reason; he forwards the request to the Manager’s assistant (context handler), who asks the Manager (PDP) to decide. The Manager pulls up the relevant rule, realizes she needs facts, and asks for Sara’s attributes; the assistant fetches them from the Clerk (PIP) and brings them back. The Manager evaluates the rule against the request and the facts, produces “permit” or “deny,” and sends it back down the chain to the Doorkeeper, who finally opens or blocks the door. Every component did exactly one job, and the request touched each in turn.

Why split it into four? The payoff of separation

This may look like bureaucracy — why not let one component do everything? Because the separation buys properties you cannot get any other way, and they are the same benefits the PBAC article promised, now given a concrete structure.

One decider, many doors. Because deciding is separated from enforcing, a single PDP can serve dozens of PEPs — every application, service, and gateway asks the same Manager, so they all enforce the same rules identically. Consistency stops being a hope and becomes a property of the architecture. Change rules without touching apps. Because authoring (PAP) is separated from deciding and enforcing, the Owner can rewrite the house rules and every decision changes at once, with no PEP redeployed. Swap data sources freely. Because information (PIP) is separated from decision, you can add a new attribute source — a risk feed, a new directory — without changing the policy logic or the enforcement code. And audit in one place: since all decisions flow through the PDP, there is a single point to log “who asked for what, and what was decided,” instead of reconstructing it from scattered application logs. Each seam in the architecture is there to let one concern change without disturbing the others — which is exactly what makes large authorization systems maintainable.

What the PDP actually evaluates: the policy structure

We have treated “the rules” as a black box; XACML also gave us a precise structure for them, and it is the same anatomy you met in the PBAC article, now named formally. The rulebook is a nested hierarchy:

A request arriving at the PDP is likewise structured — it describes the subject (who), the resource (what), the action (which operation), and the environment (the context) — the same four attribute categories the ABAC article introduced. The PDP matches this request against the targets in the policy tree to find which rules apply, evaluates their conditions against the attributes, and folds the results together. To make that concrete, here is one request and one rule in readable pseudo-form — stripped of XACML’s real XML, which would be many times longer:

REQUEST                              RULE  (effect: Permit)
  subject.role   = "support-agent"     target:    action == "view"
  action         = "view"                          resource.type == "account"
  resource.type  = "account"           condition: subject.role == "support-agent"
  resource.id    = 4471                            AND ticket.open_for(resource) == true
  environment.time = 14:30                         AND environment.time in business_hours

The target is the cheap filter that decides whether this rule is even relevant to the request (it is — the action is view on an account); the condition is the finer test evaluated against the gathered attributes (is Sara’s role right, is there an open ticket, is it business hours?); and the effect is what happens if both pass (Permit). Every rule in every engine you will meet has these same three parts, however different the syntax — which is exactly why learning the shape matters more than learning any one language. This also exposes the piece that makes multi-rule policies actually work: what happens when two rules both match and disagree?

Combining algorithms: resolving disagreement

Here is a problem that appears the moment you have more than one rule: two rules match the same request and disagree — one says Permit, the other says Deny. Which wins? XACML’s answer is the combining algorithm, a declared, deterministic rule for folding many sub-decisions into one. You attach a combining algorithm to every policy and policy set, and it decides how conflicts and gaps resolve.

This is not a footnote; it is a genuine security decision. deny-overrides is the conservative choice — it guarantees that if any rule refuses, access is refused, so a forgotten grant never silently opens something a deny meant to close. Choosing permit-overrides instead flips the safety posture, and choosing first-applicable makes rule ordering meaningful in a way that can surprise you. Whenever you evaluate a policy engine, one of the first questions to ask is “what is the default combining behavior, and can I reason about what happens in the gaps?” — because that behavior, not any single rule, governs the whole.

The decision is not just yes or no

A subtle but important lesson: a XACML PDP returns one of four values, not a boolean. Collapsing them too early is a classic source of bugs.

The distinction matters because each value calls for different handling. NotApplicable means the PDP has no opinion — nothing matched — and it is the PEP’s job to decide how to treat silence, which for security should almost always be deny by default (a gap is not permission). Indeterminate means something broke — the PIP could not supply a required attribute, or a policy errored — and treating that as a plain “deny” can mask an outage or a misconfiguration that deserves an alert, while treating it as “permit” is a security hole. A mature system distinguishes “no rule applied,” “a rule denied,” and “evaluation failed,” and handles each deliberately. Alongside the decision, the PDP may also return obligations and advice — the “permit, but log it” and “permit, and show a notice” extras you met in the PBAC article — which the PEP is responsible for carrying out.

XACML the language versus XACML the architecture

Now the crucial framing that makes this whole article pay off. XACML shipped two things: an XML language for writing policies, and the four-component architecture for evaluating them. History treated them very differently. The XML language was powerful but notoriously verbose — a rule that reads as one line of Rego could sprawl across dozens of lines of nested XML — and it never won developers’ hearts; new systems almost never write raw XACML today. But the architecture was a quiet triumph. The PEP/PDP/PIP/PAP separation, the request-decision flow, combining algorithms, obligations, the four-value decision — these became the conceptual foundation of essentially every authorization engine built since.

Where the components live in real systems

The architecture is abstract about deployment on purpose, and real systems place the PDP in three broadly different ways — a choice with real consequences for latency, freshness, and blast radius that the decentralized-authorization article develops in full. The PDP can be a library compiled into the application (fastest, no network hop, but a copy per app to keep in sync), a sidecar running next to each service (local and fast, decoupled from app code — the common cloud-native pattern, e.g. OPA as a sidecar), or a central service every app calls over the network (one authoritative decider, but a network dependency on the request path and a single thing to keep highly available). The PEP is almost always in the application or its gateway, because enforcement must happen where the action does; the PAP is typically a separate authoring and CI system; and the PIPs are wherever your attributes already live. There is no universally right placement — only trade-offs among speed, consistency, and coupling, the same tensions this whole domain keeps circling. The lesson is that the four roles are logical, not physical: they can collapse into one process or spread across a continent, and recognizing them is about spotting the four jobs, not four separate servers.

A worked example: Sara at the cashback app

Trade the venue for the running fintech and the mapping holds exactly. Sara, a support agent, opens the console and clicks to view customer account #4471. The console’s PEP intercepts the click and, instead of deciding anything itself, packages a request — subject: Sara (role support-agent); action: view; resource: account #4471 — and sends it to the PDP. The PDP loads the authorization policy the security team authored through the PAP (“a support agent may view an account only if they have an open ticket assigned for it, during business hours”). Finding it needs facts, the PDP asks for attributes: the PIP supplies Sara’s role and shift from the directory, the ticket system’s record that ticket #90210 is open and assigned to Sara for this customer, and the current time from the environment. The PDP evaluates the rule against these, gets Permit, and returns it — with an obligation to log the access. The PEP receives Permit, carries out the obligation by writing the audit entry, and renders the account. Change the scenario to after hours, and the same flow returns Deny; the same PEP now blocks the view. One policy, one decider, many possible enforcers — and every piece of that sentence is a XACML component.

Notice what this buys the fintech. The identical policy governs the mobile app, the web console, and tomorrow’s fraud-review tool, because each only needs a PEP that asks the shared PDP. When compliance tightens the rule, the security team edits it once at the PAP and every surface obeys within seconds, no app redeployed. When a new attribute becomes relevant — say a device-risk score — it is added at a PIP without touching a line of policy or enforcement code. The architecture did not just answer Sara’s request; it made the whole system changeable, which at scale matters even more than any single decision.

Recap

The XACML reference architecture is the blueprint underneath essentially every authorization system:

1. Four roles, cleanly separated. The PEP (Doorkeeper) asks and enforces, the PDP (Manager) decides, the PIP (Clerk) supplies facts, and the PAP (Owner) authors rules ahead of time — with a context handler ferrying requests and attributes between them.
2. A request flows through them in order: the PEP forwards the request, the PDP evaluates policy (published earlier by the PAP), pulls attributes from PIPs as needed, and returns a decision the PEP enforces.
3. Separation is the payoff: one decider serves many enforcers consistently, rules change without redeploying apps, data sources swap freely, and every decision audits in one place.
4. Policies are structured as rules (target, condition, effect) inside policies inside policy sets, with combining algorithms (deny-overrides and friends) resolving conflicts — a real security choice — and decisions come in four values (Permit, Deny, NotApplicable, Indeterminate), not a bare boolean.
5. The XML language faded, but the architecture won everywhere. OPA, Cedar, Verified Permissions, and cloud IAM are all this pattern — so learn XACML for its shape, which is universal, not its syntax, which you will rarely write.

Three questions to test yourself

1. Using the venue analogy, explain the difference between the PEP and the PDP, and separately between the PIP and the PAP. For each pair, give the one-sentence tell that keeps them straight (“facts-now versus rules-before,” and so on).
2. A request arrives, two rules match, one Permits and one Denies, and the policy uses deny-overrides. What is the result, and why is the choice of combining algorithm described as a security decision rather than a technical detail? What would change under first-applicable?
3. A PDP returns Indeterminate because a PIP could not supply a required attribute. Explain why collapsing this to “deny” can be dangerous, why collapsing it to “permit” is worse, and what a mature PEP should do with NotApplicable versus Indeterminate.

Hands-on exercises

1. Map a system you use to the four roles. Pick any platform with externalized authorization (Kubernetes with OPA/Gatekeeper, a service mesh, a cloud authorization service). Identify concretely what plays the PEP, the PDP, the PIP, and the PAP, and where the policy is stored. If any role is missing or merged into another, note it — that tells you something about the system’s trade-offs.
2. Trace a request on paper. Take the cashback rule (“support agent may view an account only with an open assigned ticket, during business hours”) and write out the ordered messages between PEP, context handler, PDP, PIP, and PAP for one Permit case and one Deny case. Mark which step is setup-time and which are request-time.
3. Choose combining algorithms deliberately. Write three plain-language rules for a resource where at least two can apply to the same request, then decide the outcome under deny-overrides, permit-overrides, and first-applicable. Note where the three disagree — that gap is exactly the security decision the combining algorithm makes for you.