Why architecture matters here
Authorization is where breaches become catastrophic. Authentication — proving who you are — is a solved-enough problem with known primitives; the incidents that make headlines are overwhelmingly authorization failures: a user who could read another tenant's data, an API endpoint that never checked ownership, a support tool that granted god-mode to anyone who could reach it. The architectural stakes are high because authorization is checked on the hot path of every request, must be consistent across dozens of services, and is the single control standing between a compromised or curious account and the data it should not touch. Getting the model right is not a nicety; it is the difference between a limited incident and a company-ending one.
RBAC earned its dominance because it matches how organizations actually think. People have jobs, jobs imply permissions, and a role is the durable name for 'the permissions this job needs.' Assigning a new hire the 'billing-analyst' role is a one-line, auditable, reversible act, and an auditor can answer 'who can issue refunds?' by listing everyone with the refund permission. That legibility — access as a small, human-readable set of role assignments — is RBAC's enduring strength, and for a large class of systems it is entirely sufficient.
RBAC's limit is context. A role is a static grant: an 'editor' can edit, full stop. But real rules are conditional — an editor should edit only articles in their section, only during business hours, only from a trusted network, only if the article is not locked for legal review. Encoding those conditions in RBAC forces you to mint ever-more-specific roles ('editor-sports-daytime-trusted-net'), and the role count explodes combinatorially until the model that was supposed to simplify access becomes an unmanageable thicket. This is the exact pressure that gives rise to ABAC.
ABAC dissolves the explosion by moving the conditions out of the role and into a policy evaluated against attributes at request time. Instead of a role per combination, you write one policy — 'permit edit when subject.section == resource.section and environment.time in business_hours' — and it covers every editor and every article without enumerating them. The power is real, but so is the cost: policies over free-form attributes are harder to reason about, harder to audit ('who can edit this article?' now requires evaluating a policy against every subject's attributes rather than reading a list), and only as trustworthy as the attributes feeding them. The architectural truth most mature systems converge on is that these are not rivals but layers: RBAC gives coarse, legible structure, and ABAC adds the fine contextual conditions RBAC cannot express — which is why the sections that follow treat the combination, not a winner.
The architecture: every piece explained
Top row: the inputs to every decision. The subject is the user or service making the request, carrying its assigned roles and its attributes (department, clearance, tenant, manager). The resource is the object being acted on, with its own attributes (owner, classification, tenant, status). The action plus environment is what is being attempted (read, write, approve) together with contextual facts — time of day, source IP, device posture, a computed risk score. RBAC uses only the subject's roles; ABAC can use all four categories, which is precisely why it can express rules RBAC cannot.
Middle row: the two evaluation engines. The RBAC check is a lookup: expand the subject's roles (following any role hierarchy, so 'admin' inherits 'editor') into a permission set and test whether the requested action-on-resource-type is in it. It is fast, cacheable, and trivially auditable. The ABAC policy engine evaluates a boolean expression — the policy — over the request's attributes, returning permit or deny and optionally obligations (e.g. 'permit, but log this' or 'permit, but redact field X'). The decision is the combined verdict; a common composition is 'RBAC must permit AND the ABAC policy must permit,' so roles set the outer envelope and attributes tighten it.
Bottom rows: where the decision lives and is enforced. The classic XACML vocabulary names two components. The Policy Decision Point (PDP) is the centralized brain that evaluates policy against the request context and returns a verdict; keeping it central makes policy versionable, cacheable, and consistently auditable. The Policy Enforcement Point (PEP) is the gate at the door — the API gateway or the service middleware — that intercepts the request, asks the PDP, and permits or blocks accordingly. The ops strip is the discipline that keeps it trustworthy: versioning policies like code, emitting a decision log for every verdict, defaulting to deny, and periodically reviewing that access still matches least privilege.
Two design choices in this picture repay careful thought. The first is where the PDP lives: a truly central, networked PDP gives you one place to version and audit policy but puts a remote call on every request's hot path, so mature deployments often distribute the evaluation — shipping the compiled policy and the relevant attributes to a sidecar or an in-process library co-located with each service — while keeping policy authorship and distribution central. You get consistency and auditability without the latency and the single point of failure. The second is the combining algorithm: when RBAC and ABAC, or several ABAC policies, both have an opinion, the system needs a deterministic rule for merging them. The safe default is deny-overrides — any deny wins — because it fails closed, and it is why a request that RBAC would permit but an ABAC policy denies is correctly blocked. Making these two choices explicit, rather than letting them emerge by accident from where someone happened to put an if statement, is most of what separates a defensible authorization architecture from a pile of scattered checks.
End-to-end flow
Trace an expense-approval request through a combined model. A manager, Dana, clicks 'approve' on a $4,000 expense. The PEP in the expenses service intercepts the call and assembles the decision context: subject = Dana with role 'manager', attributes {department: sales, approval_limit: 5000}; resource = expense #812 with attributes {department: sales, amount: 4000, status: pending}; action = approve; environment = {time: 14:20, network: corp}. It ships this context to the PDP.
The PDP evaluates in two layers. First the RBAC gate: does 'manager' carry the 'approve-expense' permission at all? Yes — so the coarse envelope is open. Then the ABAC policy: 'permit approve when subject.department == resource.department AND resource.amount <= subject.approval_limit AND resource.status == pending AND environment.network == corp.' Every clause holds — same department, 4000 under Dana's 5000 limit, pending, on the corporate network — so the PDP returns permit, perhaps with an obligation to write an audit record. The PEP lets the approval through. Note what neither model could have done alone: RBAC alone would let any manager approve any expense of any size; ABAC alone would have no notion of the 'manager' structure to hang the policy on. Layered, they express exactly the intended rule.
Now perturb the request to see the boundaries. Same expense, but $6,000: the amount clause fails against Dana's 5,000 limit, the PDP returns deny, and the PEP blocks it — no new role needed, the policy simply evaluated false. Or a different manager, Wei, from the engineering department tries to approve this sales expense: the department clause fails, deny. Or Dana approves from home over a personal VPN that the environment classifies as untrusted: the network clause fails, deny — the same subject, same resource, same action, denied purely on context. Each of these is a one-attribute difference producing a different verdict, which is the whole reason ABAC exists: the rules are conditional on the full state of the request, not just on identity.
Zoom out to the audit view, because that is where the layered model earns its keep operationally. Every one of those verdicts — permit and deny alike — is emitted as a structured decision log entry: who, what, on which resource, under what attributes, which policy version, and the outcome. When a quarter-end review asks 'show me every approval over $3,000 in sales and the policy that allowed it,' the answer is a query over decision logs, not an archaeological dig through service code. And when policy must change — say the approval limit logic moves from a per-user attribute to a per-role tier — you version the policy, roll it out through the central PDP, and the change takes effect everywhere at once, with the old and new versions both attributable in the logs. That combination of a legible role structure, contextual policy, central decision point, and complete decision log is what makes authorization something you can actually defend in an audit rather than merely assert.
One more property of the flow is worth naming: the model degrades safely under partial information. If an attribute the policy needs is missing or its source is unreachable — the approval-limit service is down, say — a well-built PDP does not guess; it treats the absent attribute as a failure to satisfy the clause and, under deny-overrides, returns deny. That is the correct behavior for a security control: an outage in the attribute plane becomes a temporary loss of access, never a temporary loss of enforcement. Contrast the tempting-but-wrong alternative of 'if we cannot evaluate the amount clause, assume it passes,' which would turn every dependency hiccup into an over-permissive window. Designing the flow so that missing context fails closed — and alerting loudly when it happens, so the underlying outage gets fixed rather than silently denying legitimate users — is the difference between an authorization layer that is merely convenient and one that is genuinely a control.