Skip to content

CONCEPT Cited by 7 sources

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

  • sources/2026-09-15-cloudflare-workers-granular-authorization — contrast: RBAC-with-resource-scope, not ABAC (2026-09-15). Cloudflare's granular Worker authorization gets its granularity from a fixed role × scope product (4 roles, pinnable to one resource), not from evaluating attributes of principal/resource/context per request. Useful as the RBAC end of the spectrum this page contrasts against: no policy DSL, no per-request attribute evaluation — the "fine-grained" part is which resources the role applies to, and it explicitly trades attribute-expressiveness for a small, legible role set. See fine-grained authorization.

  • sources/2026-09-03-databricks-governance-beyond-security-knowledge-context-ontology-on-the-lakehouse — ABAC extended across SQL and vector search / embeddings (2026-09-03). The Databricks DEP post enforces ABAC "at the data layer, not the application layer," so an agent's RAG retrieval inherits the querying user's row/column entitlements: "If a user cannot query a row in SQL, no agent can retrieve it via vector search or embeddings." Canonicalised as unified-permission-model-over-data-and-embeddings — the same ABAC evaluator reaching the embedding surface, closing the RAG-leak gap.

  • sources/2026-08-03-redpanda-out-of-band-policy-engine-governance-ai-agents-cant-ignore — ABAC shipped inside an agent-governance policy engine (2026-08-03). Redpanda's OBPE ships ABAC as "fine-grained, attribute-driven permissions across agents, tools, and connections, and the substrate that role- and group-based models sit on." Canonical agent-altitude example: "Tag data internal-only, and agents serving external users can't reach it regardless of the credential" — attribute (data tag) + principal attribute (external-serving agent) over-riding a credential the RBAC model would have allowed. Enforced out of band at the MCP boundary.

  • sources/2026-08-10-databricks-how-to-ground-genie-agents-in-both-structured-data-and-documents-without-losing-governance — ABAC as one of four access layers governing an AI agent's structured data. The Genie Agents governance post tabulates ABAC ("which policy applies, and to what") alongside object privileges, row filters, and column masks, and — because the agent runs with the end user's credentials — treats tag-driven ABAC as the mechanism that lets one policy (e.g. mask every pii:email column) cover whatever tables the agent reaches. No new ABAC mechanism; a reuse of the 2026-05-13 GA capability in an agent-governance context.

  • sources/2026-05-28-databricks-advancing-apache-iceberg-on-databricks-iceberg-v3-ga-open-sharing-and-unified-governance — Cross-engine ABAC dimension (third canonical instance after Convera + Cedar at API-authorization altitude and the 2026-05-13 UC GA at table-storage altitude). Adds the cross-engine axis: UC ABAC policies authored once are now evaluated server-side during Iceberg REST Catalog Scan Planning for any conforming Iceberg engine — Spark / DuckDB / Trino / Flink / Snowflake on Iceberg 1.11+. The policy-engine boundary moves from "the catalog vendor's compute" to "any engine that speaks the scan-planning client". Canonicalised as concepts/attribute-based-access-control + scan-planning-as-policy-enforcement-point. Beta release; sibling extension to the GA Databricks-compute-only ABAC face from 2026-05-13.

  • sources/2026-05-13-databricks-abac-row-filtering-and-column-masking-policies-governed-tags — Unity Catalog ABAC GA. Canonical wiki instance of ABAC at the table-storage governance altitude (distinct from the prior Convera + Cedar canonical at the API-authorization altitude). ABAC policies evaluate tag-based conditions to apply row filters

  • column masks to all matching objects across catalogs/schemas. Three GA enhancements named: (a) policy limits grew 10× across every scope (10K+ per metastore, 100+ per catalog/schema); (b) session identity evaluation for views and functions (closes the view-as-bypass failure mode where current_user() would resolve to the view creator); (c) single VARIANT UDF can mask INT / DOUBLE / DECIMAL / STRUCT columns at once via type-erasure (see single-variant-udf-for-multi-type-masking). Composes with governed tags (the attribute substrate) and agentic data classification (the auto-tagger) to produce the full organize → detect → protect pipeline canonicalised in tag-driven-attribute-based-access-control. Customer testimonials emphasise the policy-count payoff: Udemy (Rajit Saha) "Fewer policies, lower costs, surgical precision"; Atlassian (Gerald Nakhle) "significantly reducing the operational overhead of managing permissions at scale."

  • sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization — Cedar policies combining principal-role conditions + resource-type + path + status attributes; the pre-token-generation-hook explicitly named as the attribute-sourcing mechanism.

Merged aliases

  • group-based-access-control- condition-tag-iam
  • cross-engine-abac- row-level-security
  • runtime-policy-enforcement
Last updated · 766 distilled / 2,225 read