RBAC vs ABAC: Which Authorization Model Should You Use?

When building complex business systems, authorization requirements quickly outgrow basic role assignments. For example:

• "Can this user approve an expense report?" (RBAC question)
• "Can this user approve this specific expense report if the amount exceeds €50,000, during off-hours, when they are in the same department as the submitter?" (ABAC question)

Choosing between Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC)—or combining them in a hybrid policy engine—is a foundational architectural decision.

RBAC EVALUATION:
User ---> Assigned Roles ---> Granted Capabilities ---> Allow / Deny

ABAC EVALUATION:
[Subject Attributes] (User, Clearance, Department)
         +
[Resource Attributes] (Expense Amount, Sensitivity, Owner)
         +
[Action Attributes] (Approve, Void, Export)
         +
[Environment Attributes] (Time of Day, IP Range, Device Trust)
         |
         v
+-------------------------------------------------------------+
|                     POLICY EVALUATION ENGINE                |
|  Rule: Allow IF Subject.Dept == Resource.Dept               |
|            AND Resource.Amount < Subject.ApprovalLimit       |
|            AND Environment.IsCorporateVpn == true            |
+-------------------------------------------------------------+
         |
         v
    Allow / Deny

Architectural Comparison Matrix#

Implementing a Hybrid Policy Engine#

Pure ABAC engines (like XACML or raw OPA policies) can be overwhelming for standard user interfaces because rendering navigation bars requires knowing which buttons a user can see without evaluating dynamic policies against 1,000 un-fetched records.

In modern business software, the most resilient pattern is a Hybrid Tier:

1. RBAC as the Coarse Gate: Determine if the user has the baseline capability (expenses.approve).
2. ABAC as the Contextual Policy Guard: If the coarse check passes, evaluate fine-grained attributes of the specific target entity.

// In Alegor: Hybrid Policy Evaluation Pattern
class ExpensePolicy
{
    public function approve(User $user, Expense $expense): Response
    {
        // 1. Coarse RBAC verification
        if (! $user->hasCapability('expenses.approve')) {
            return Response::deny('Missing required role capability.');
        }

        // 2. Dynamic ABAC Attribute evaluation
        if ($expense->amount_cents > $user->approval_limit_cents) {
            return Response::deny('Expense exceeds your discretionary approval threshold.');
        }

        if ($expense->user_id === $user->id) {
            return Response::deny('Self-approval of personal expenses is strictly prohibited.');
        }

        if ($expense->department_id !== $user->department_id && ! $user->isGlobalAuditor()) {
            return Response::deny('Cross-department approval requires executive auditor clearance.');
        }

        return Response::allow();
    }
}

Decision Guide#

• Use Pure RBAC if your permissions can be completely represented as fixed capabilities assigned to identifiable job functions.
• Adopt Hybrid RBAC + ABAC if access decisions depend on resource values (e.g. monetary amounts, confidentiality flags, patient relationship, or geo-location).

Explore our Permissions & Authorization Module or read Designing SaaS for Enterprise Customers.