RBAC and ABAC

Two ways to express an access policy

Role-based access control, or RBAC, groups permissions into roles and assigns identities to those roles. Attribute-based access control, or ABAC, evaluates properties of a subject, resource, action, and environment against policy. Both are ways to express Authorization, and neither removes the need for trustworthy inputs and effective enforcement.

A role can represent a responsibility such as support agent or payroll approver. An attribute might identify a ticket's customer, an employee's assigned region, the classification of a document, or a device's management status. The useful choice depends on the rules the organization needs to explain and maintain.

Start with a support team's job

Imagine a fictional software company gives its support-agent role permission to view and update support tickets. This is easy to explain, but the business also promises that regional teams will access only their own customers' tickets.

One approach creates a separate role for every combination of job and region. As new restrictions arrive, the number of roles can grow. Another approach uses the support role as a baseline and checks an assignment or region attribute for the individual ticket.

The combined rule might say: an active support agent may update an open ticket assigned to their team. That sentence describes a useful boundary, but implementation needs reliable account status, ticket status, and team membership. A stale assignment can produce the wrong answer even when the policy engine follows the rule perfectly.

Make ambiguity visible

Now introduce a supervisor who needs temporary access to another region. Does a supervisor role override the region restriction, or does a separately approved exception supply the missing permission? An unclear answer can become an accidental bypass.

Write down the intended result for normal access, an exception, and a conflicting condition. For example, a disabled account should not regain access merely because it still carries a privileged role. Decide how the system resolves those cases instead of relying on an administrator's intuition during an incident.

Compare administration costs

RBAC can make routine assignment easier when jobs are stable and permissions align with them. ABAC can express conditions that would otherwise require many role combinations. However, attribute quality, policy complexity, and troubleshooting become important operational responsibilities.

NIST SP 800-162 provides a detailed ABAC reference. NIST's archived RBAC material is useful for the historical model, rather than current product or deployment guidance. A hybrid design can be appropriate; a fashionable acronym is not evidence that the design fits the service.

Build a small decision table

Use four fictional requests: an assigned agent updates an open ticket, an unassigned agent tries the same action, a supervisor uses an approved exception, and a disabled account retains an old role. Write the expected allow or deny result and the facts needed to reach it.

Then change one fact at a time. This exercise exposes dependencies and makes reviews more concrete than asking whether the application “supports ABAC.” Continue with Access control for the surrounding process and Least privilege for deciding how much capability each role or rule should grant.