Skip to content

CONCEPT Cited by 1 source

Attribute-based access control (ABAC)

What it is

Attribute-based access control (ABAC) decides whether a principal may perform an action on a resource by evaluating a policy over attributes of all three (plus context) — not just by matching the principal's role(s).

A typical ABAC rule:

permit P to do A on R
  when  P.role == "PAYMENT_INITIATOR"
    &&  R.accountType == "BUSINESS"
    &&  R.status == "ACTIVE"
    &&  ctx.tx_amount <= P.daily_limit

Contrast with RBAC ("if role in {Admin, Operator} then allow") — role-only policies cannot encode per-resource / per-transaction / per-context rules without exploding the role count.

Why it matters

ABAC is the natural answer to two forces:

  • Combinatorial policy space. Role × resource-type × action × context combinations explode quickly; ABAC lets each rule be declarative over the attributes rather than enumerating the cross product.
  • Regulated / financial workloads. Rules like "only initiators in the customer's region, during business hours, under their per-day limit, on active business accounts" are naturally ABAC, awkwardly RBAC.

ABAC is rarely pure ABAC

In production, policy sets almost always combine ABAC + RBAC + sometimes ReBAC (relationship-based, e.g. "this user is a member of this tenant's group") in one language. Convera's Cedar policy set shows this directly:

  • principal in convera_connect_authz::userGroup::"..." — RBAC / ReBAC via group membership.
  • when { principal.role.contains("UPDATE_USER_STATUS") && resource.type == "PUT" } — ABAC via principal/resource attribute comparisons.

Cedar as a language is neutral — it doesn't force one model. The schema + policies encode whichever mix fits the authorization model.

Attribute sourcing is the load-bearing design choice

For ABAC to be trustworthy, attributes must come from authoritative sources and cannot be spoofed by the client:

  • In the token. Attributes injected into the JWT at issue time by a pre-token-generation hook that reads from RDS / DynamoDB. Cannot be spoofed because the token is signed.
  • In the request context. Request metadata (source IP, time, requested resource path) is derived by the authorizer, not client-supplied.
  • In the resource store. Resource attributes (R.accountType, R.status) looked up server-side before evaluation.

Client-supplied attributes cannot be trusted without independent verification, which reduces ABAC to "RBAC with extra steps."

Performance implication

ABAC policies can reference many attributes per rule. Naive evaluation would require per-request lookups of principal + resource attributes. The Convera pattern avoids this by putting principal attributes in the JWT (one token → many requests) and colocating resource attributes with the request itself. Combined with API Gateway's authorizer-decision cache, this delivers submillisecond repeat-request latency.

Seen in

Last updated · 200 distilled / 1,178 read