Three ways to answer who may do what
Role-based access control assigns permissions to roles and roles to people. Attribute-based access control evaluates attributes of the subject, the resource, the action and the environment against rules. A policy engine is the software that evaluates such rules, and it can implement either model or a mix. These are not rival products so much as different levels of the same decision.
Choosing between them is a question of how many distinct situations your rules must express and how often those rules change.
Role-based access control
RBAC is easy to explain and audit. A role such as billing analyst carries a fixed set of permissions, and membership is reviewed periodically. It works well where job functions are stable and permissions are coarse. It struggles when exceptions multiply. Organizations that need a role for every combination of team, region and data type end up with thousands of roles, a problem often called role explosion.
Attribute-based access control
ABAC lets a rule say that a clinician may read a record when the patient is assigned to the clinician's department and the request comes from a managed device. NIST describes ABAC as granting access based on attributes and policy rather than identity alone. The strength is expressiveness and finer control without a role for every case. The cost is governance: attributes must be accurate, current and consistently named, and rules are harder for non-specialists to read.
- Subject attributes: department, clearance, employment status, agent type.
- Resource attributes: classification, owner, region, sensitivity.
- Action attributes: read, write, export, approve.
- Context attributes: time, device posture, network location, risk score.
Where policy engines fit
A policy engine separates the decision from the application. The application sends a request describing subject, action and resource, and the engine returns a decision based on current policy and data. This keeps authorization logic out of application code, so rules can change without a release. Engines such as Open Policy Agent and Cedar support both role-style and attribute-style rules in the same policy set.
Relationship-based models, which decide by the connection between a user and a resource, are a further option for sharing-heavy products. The principle is the same: express the rule declaratively and evaluate it centrally.
Choosing and migrating
Most organizations do not replace RBAC. They keep roles for broad entitlements and add attribute checks where roles are too blunt, such as data classification or location. Start by listing the ten access decisions that cause the most exceptions or incidents, and model those as attribute rules first. Measure the number of roles, the number of exceptions and the time to grant access before and after. If those numbers do not improve, the added complexity is not paying for itself.
A quick decision guide
Use roles where job functions are stable and permissions are coarse. Add attributes when the same role needs different access by region, data class or device state. Use a policy engine when several applications need the same decision logic or when rules change faster than release cycles. If your team cannot keep attributes accurate, fix that first, because precise rules built on unreliable data produce confident wrong answers.
Whatever you choose, keep the decision interface simple: subject, action, resource and context in, decision and reason out. That interface lets you change the model later without rewriting every application.
