A branch manager can approve purchases, but only for their branch, within a spending limit, and not requests they created themselves. The manager role expresses one part of that rule. The rest depends on the particular request and the circumstances of approval.
This is a useful way to compare RBAC and ABAC. The question is not which acronym is newer. It is where the rule should live, where its inputs come from, and how to explain a refusal to someone who believes they have the necessary authority.
A role can carry constraints as well as permissions
RBAC groups permissions into roles assigned to users. A requester creates a purchase request, an approver authorises it, and an auditor reads completed decisions. Roles need not match job titles in an HR directory; one person may hold several distinct responsibilities.
RBAC is not limited to checking a single label. It supports hierarchies, constraints and separation of duties, as the NIST RBAC guidance explains. Preventing someone from approving their own request does not, by itself, require replacing the entire role model.
The difficulty appears when every combination of branch, purchase category and temporary exception becomes another role. Managers can no longer confidently review who needs each bundle. Giving everyone a broad role avoids that administration problem by weakening the boundary instead.
Attributes bring the decision closer to the request
ABAC evaluates properties of the participant, resource, operation and, where relevant, environment. That is the model defined in NIST SP 800-162. Purchasing might use the assigned branch, amount, request author and approver's spending authority.
The rule can read like a business sentence: an active approver may authorise a request from their branch within their limit, provided they did not create it. The role still helps; attributes refine its scope. Simple permissions do not all need to move into an elaborate policy system.
If the decisive fact is a relationship such as “assigned reviewer for this request”, represent that explicitly. Relationship-based access control can be useful for such cases. Neither a broad role nor general profile attributes should stand in for a missing assignment.
Who can change the facts that determine access?
A perfectly written rule is unsafe if it takes the branch from an unrestricted value supplied by the user. It is then evaluating a claim the requester made about themselves. Inputs need trustworthy sources: a verified assignment, an authoritative record or validated identity information.
Every important attribute needs an owner, an update process and an acceptable age. If someone transfers branches while an application still sees yesterday's membership, a correct policy can produce the wrong decision. Follow the update through caches and information embedded in existing tokens.
The object changes too. Somebody edits the purchase amount after approval. Permission for the earlier request must not automatically carry over. Bind the decision to the reviewed version and recheck consequential conditions before execution. A policy engine does not supply that business safeguard merely by being installed.
Hiding a button is not server-side enforcement
Removing the Approve button improves the interface but does not stop a direct API request. Equivalent controls belong on APIs, exports, search and background operations. For queued work, determine whose authority it uses and whether that authority must still be current when the job executes.
Object boundaries matter. Permission to read purchase requests does not mean permission to read every organisation's requests. OWASP's authorisation guidance covers object-level checks, validation on every request and default denial.
An unavailable policy service should not become a temporary permission to do anything. Operational failure should still be distinguishable from an ordinary denial: support needs to know whether an assignment is absent or an information source is down. The user can receive a useful explanation without exposing another person's records or internal secrets.
Why was it allowed yesterday and refused today?
An investigation needs the rule, its version, the outcome and appropriate context for that decision. Today's HR directory cannot always explain yesterday's authorisation. But recording decisions must not become an excuse to copy whole documents and unnecessary personal information into logs.
Open Policy Agent decision logs illustrate recording policy queries and filtering sensitive content. The product choice is secondary to the ability of appropriately authorised staff to reconstruct why access was allowed or denied.
Define how overlapping rules combine. One grants managers general approval authority; another prohibits approving their own requests. Which result wins? What happens when a required attribute is missing? Capture those cases in tests before changing the policy.
Change the model through disputed decisions
Start with cases that repeatedly require exceptions. Record the expected results for a same-branch request, another branch, self-approval, a revised amount and an expired assignment. Tests should preserve legitimate work as well as block excess access. One successful administrator login demonstrates very little.
A proposed policy can initially be compared with the current one using approved test data or an observation mode that does not grant authority. Review disagreements with the process owner. Rollback also requires scrutiny: restoring an older policy must not restore access deliberately withdrawn.
Purchasing may ultimately need only a few stable roles with request-level constraints. Another product may justify richer attributes and relationships. Choose by the ability to express the rules, maintain their inputs and explain decisions, not by a promise that a new model will eliminate every future exception.