Policy foundations

RBAC, ABAC and delegated authority

Roles simplify common access. Attributes add context. Delegation explains who authorised the action.

Policy comparison

Combine baseline, context and accountable authority.

RBAC, ABAC and delegated authority working togetherRole-based access creates a baseline. Attribute-based access evaluates identity, resource and context. Delegated authority adds accountable purpose, scope and expiry before a decision is enforced.RBAC · REPEATABLE BASELINEIDENTITYKnown actorROLEResponsibilityBASELINEExpected accessDECISIONExplainable resultABAC · CONTEXTUAL CONSTRAINTIDENTITYATTRIBUTESRESOURCECONTEXTPOLICYEvaluate conditions+ delegationDELEGATED AUTHORITY · SCOPE · EXPIRYRBAC and ABAC comparisonRole-based and attribute-based controls are shown as separate paths that both contribute to a governed decision, with delegated authority adding accountable scope.RBAC · BASELINEIDENTITYROLEEXPECTED ACCESSABAC · CONTEXTIDENTITY + ATTRIBUTESRESOURCE + CONTEXTPOLICY CONDITIONSDELEGATED AUTHORITYGOVERNED DECISIONRole + context + accountable scope
Roles simplify repeatable access; attributes constrain context; delegation records accountable authority, scope and duration.
01

Role-Based Access Control

RBAC answers who should receive access because of a recognised role—such as HR administrator, finance manager, service desk operator, application administrator or contractor coordinator. It is understandable and scalable, but broad roles can accumulate privilege and rarely express every contextual boundary.

02

Attribute-Based Access Control

ABAC evaluates characteristics such as department, organisation, location, assurance level, employment status, classification, device state, business unit, project, time and current delegation status. It can express precise conditions, but only when attribute quality, policy ownership and explainability are governed.

03

Delegated authority

Delegation answers a different question: who authorised this person to act, for what purpose, against which resource, and until when? It adds accountable authority to role and attribute context.

04

Where each model alone falls short

Consider a "Finance" role granting broad transaction access: RBAC alone cannot express that one holder is approved to spend up to $5,000 while another is approved up to $50,000, or that a regional finance officer should only see transactions for their own region—the role is the same, but the appropriate authority is not. ABAC alone can encode the spend threshold and region as attributes, but on its own it cannot explain who decided this particular person should hold that threshold, or for how long the arrangement is meant to last. Combining role, attributes and delegated authority produces a decision that is precise and defensible: the role sets the baseline function, attributes constrain it to the right region and context, and delegation records the accountable approval, scope and expiry behind the specific authority being exercised.

05

Use them together

A role can establish a baseline, attributes can constrain the context, and delegation can authorise a bounded exception or business action. The resulting decision should remain explainable to the person, owner and auditor.

Apply the model

Make authority explicit.

Start with the business action, accountable owner, current entitlement and platform control surface.

Talk to MAITS →