Identity & Access Management

Authorization Models: RBAC, ABAC & ReBAC

RBAC, ABAC, and ReBAC are three different answers to "what can this identity do", trading a fixed role list for progressively more dynamic, context-aware rules — RBAC stays easiest to audit at a glance, ABAC is the hardest since its effective permissions are computed rather than enumerated, and ReBAC's explicit relationship graph lands in between; most real systems eventually blend more than one.

RBAC assigns permissions to roles and users to roles — simple and auditable at small scale, but tends toward role explosion as real access needs (this team, this region, this specific record) outgrow any fixed role hierarchy
ABAC evaluates a policy against attributes of the subject, resource, action, and environment at request time (e.g. "finance dept AND business hours AND owns the record") — far more expressive than a role list, but harder to audit because the effective permission set is computed, not enumerated
ReBAC (relationship-based, Zanzibar-style) models permissions as a graph of relationships — user is a member of group, group is an editor of document — and fits sharing/collaboration products (docs, drives, project tools) far more naturally than roles or flat attributes
Centralizing authorization in a policy engine (e.g. OPA/Rego) decouples the "who can do what" decision from application code — one auditable place to change policy, instead of role checks scattered through dozens of services
Coarse-grained checks (is this token valid, does its scope cover this endpoint) belong at the edge; fine-grained, data-dependent checks (row-level, field-level) usually have to stay close to the data, since the edge often doesn't have the record loaded yet
Deny-by-default with explicit allow rules is safer than allow-by-default with explicit deny rules: a forgotten rule in a deny-by-default system fails closed (access denied); the same gap in an allow-by-default system fails open (access granted)

RBAC vs ABAC vs ReBAC
Model	Granularity	Auditability	Good fit
RBAC	Coarse — permission set per role	High at small scale, degrades with role explosion	Stable org structures, small-to-mid permission surface
ABAC	Fine — computed per request from attributes	Lower — effective permissions aren't enumerable	Context-dependent rules (time, location, department)
ReBAC	Fine — derived from a relationship graph	Moderate — traceable by walking relationships	Sharing/collaboration products, nested resource ownership

A ReBAC relationship graph

Alice's edit access to the document is derived by walking the graph (Alice -> Engineering -> editor of -> Document), not stored as a direct grant

A deny-by-default isAllowed(subject, action, resource) check

interface Policy {
    boolean isAllowed(String subject, String action, String resource);
}

class DenyByDefaultPolicy implements Policy {
    private final List<Rule> allowRules;

    @Override
    public boolean isAllowed(String subject, String action, String resource) {
        return allowRules.stream()
            .anyMatch(rule -> rule.matches(subject, action, resource));
        // no matching rule => false: fails closed, not open
    }
}

The absence of a matching rule is treated as a denial, not an implicit grant