Attribute-Based Access Control (ABAC)

Summary

Attribute-Based Access Control (ABAC) is an authorization model that evaluates access decisions based on attributes of the subject, resource, action, and environment. Unlike RBAC, which relies on predefined role assignments, ABAC policies define conditions using attribute values — such as the user's department, the request's HTTP method, or the time of day. In Keymate, ABAC policies support two authoring approaches: a visual condition builder for structured AND/OR conditions, and a free-form expression mode using the Keymate policy expression language for complex logic.

Why It Exists

Role-based access is effective for coarse-grained permission management, but many real-world authorization decisions depend on context that roles cannot capture. Consider these examples:

• "Allow access to financial reports only for users in the Finance department"
• "Allow write access to order resources only during business hours"
• "Deny access if the request originates from an untrusted network"

These conditions depend on attributes — properties of the user, the resource, the request, or the environment — that change dynamically and cannot be represented as static role assignments. ABAC enables fine-grained, context-aware authorization by evaluating these attributes at runtime.

This approach provides:

• Contextual decisions — Incorporate runtime signals like HTTP method, request path, IP address, or custom business attributes into access decisions
• Fine-grained control — Express conditions that go beyond "who" (roles) to include "what", "where", "when", and "how"
• Reduced role explosion — Avoid creating a new role for every unique combination of conditions. One ABAC policy replaces dozens of specialized roles
• Dynamic evaluation — The platform evaluates attribute values at request time, not at assignment time, so decisions automatically reflect the current state

Where It Fits in Keymate

ABAC extends Keymate's authorization capabilities beyond role-based checks. It operates alongside RBAC and other models, and can be composed into PBAC composite policies for layered decisions.

Context delivery: When a client application sends a permission check, it includes contextual attributes alongside the resource and scope request. The Access Gateway forwards these attributes — request body, headers, HTTP method, path, and custom context — to the Authorization Decision Provider.

Attribute evaluation: The Authorization Decision Provider makes these attributes available to all configured policies. ABAC policies evaluate their conditions against the attribute values and produce a GRANT or DENY result.

Boundaries

What ABAC covers:

• Evaluating conditions based on subject attributes (e.g., department, clearance level)
• Evaluating conditions based on request attributes (e.g., HTTP method, request path, headers)
• Evaluating conditions based on environment attributes (e.g., custom business context)
• Supporting nested AND/OR condition groups for complex logic
• Free-form expression mode for advanced attribute matching

What ABAC does not cover:

• Static role-based access checks — use RBAC
• Relationship-based access (e.g., "user owns document") — use ReBAC
• Composing multiple policy types into a single decision — use PBAC
• Risk scoring and adaptive decisions — use RADAC

How It Works

Context Attributes

Permission requests can include contextual attributes that ABAC policies use during evaluation. The platform organizes these attributes into categories:

Category	Examples	Description
Body	Request payload fields	The content of the request body, available as a structured attribute
Headers	HTTP headers	Request headers passed through by the enforcer
Method	GET, POST, PUT, DELETE	The HTTP method of the original request
Path	/api/v1/tenants/acme/invoices	The target URI of the original request
Context	Custom key-value pairs	Application-specific business attributes passed by the client

Condition Model

ABAC policies define conditions using a nested structure of condition groups and basic conditions:

Basic condition — A single comparison:

• attributeName — the attribute to evaluate (e.g., user.department)
• operatorType — the comparison operator (e.g., equals, not equals, contains, greater than)
• value — the expected value (e.g., Finance)

Group condition — A logical grouping of conditions:

• AND — all conditions in the group must be true
• OR — at least one condition in the group must be true

Groups can be nested, enabling complex multi-level logic such as: "(department is Finance AND level is Senior) OR (department is Executive)."

Authoring Modes

ABAC policies support two authoring modes:

Mode	Description	Best For
Conditions	Visual expression builder in the Admin Console. Constructs nested AND/OR groups with dropdown-based attribute selection. Automatically generates the equivalent expression.	Administrators who prefer a structured, visual approach
Expression	Free-form editor using the Keymate policy expression language. Provides full control over condition logic with syntax highlighting and vocabulary suggestions.	Developers and power users who need complex or custom logic

Both modes produce equivalent evaluation behavior. The visual builder generates an expression, and the expression mode allows direct editing of that expression.

Evaluation Logic

When the Authorization Decision Provider evaluates an ABAC policy:

1. Context injection — The platform converts the request's contextual attributes into key-value pairs accessible to the policy engine. The platform encodes nested objects and arrays as structured values.
2. Condition evaluation — Each basic condition compares an attribute value from the request context against the expected value using the specified operator.
3. Group resolution — Nested AND/OR groups are evaluated recursively. AND groups require all conditions to pass; OR groups require at least one.
4. Decision — If the top-level condition group evaluates to true, the policy produces a positive result. The decision strategy then determines the overall outcome.

Diagram

Example Scenario

Scenario

A company restricts write access to employee data so that only users from the HR department can modify records, and only through POST or PUT requests. An administrator creates an ABAC policy with two conditions combined using AND logic.

Input

• Actor: Authenticated user (user@example.com) with department attribute HR
• Resource: employee-data with scope write
• Action: Permission evaluation via the Authorization Decision Provider
• Context: method: POST, clientId: acme-hr-portal

Expected Outcome

• Decision: GRANT
• Why: The ABAC policy contains an AND group with two conditions: (1) user.department equals HR and (2) method is in [POST, PUT]. Both conditions are satisfied, so the condition group evaluates to true and the policy result is positive.

Common Misunderstandings

• "ABAC requires all attributes to be in the token" — No. Context attributes are passed alongside the permission request, not extracted from the token. The client application or the enforcer provides these attributes at request time.

• "ABAC replaces RBAC" — ABAC and RBAC serve different purposes. RBAC handles role-based checks efficiently. ABAC adds contextual conditions. For best results, combine them in a PBAC composite policy.

• "Expression mode and conditions mode produce different results" — They produce identical evaluation behavior. The visual condition builder generates an expression under the hood. Switching between modes changes the authoring interface, not the evaluation logic.

warning

ABAC policies depend on the quality and completeness of the attributes passed in the permission request. If a required attribute is missing from the context, the condition may evaluate differently than expected. Ensure that your enforcer (SDK, API gateway plugin, or service mesh plugin) includes the necessary context attributes in every permission check.

Design Notes / Best Practices

• Start with the visual condition builder for straightforward attribute checks. Switch to expression mode when you need logic that the visual builder cannot represent (e.g., string manipulation or computed comparisons).

• Keep attribute names consistent across your Organization. Use the policy vocabulary feature in the Admin Console to define a shared set of attribute names, ensuring that policy authors use the same attribute references.

• Combine ABAC with RBAC in a PBAC policy for layered security. Use RBAC as the first check (fast role match) and ABAC as the second check (contextual validation). Set the PBAC decision strategy to UNANIMOUS so both must agree.

tip

When designing ABAC policies, document which attributes each policy expects. This makes it clear to enforcer developers which context fields they must pass in the permission request.

Related Use Cases

• Restricting data modification operations to specific departments
• Limiting API access based on HTTP method and request path
• Implementing time-based or location-based access restrictions through custom context attributes
• Enforcing data classification policies where access depends on document sensitivity level

Related Docs

RBAC

Role-based authorization model for permission management through roles.

PBAC

Compose ABAC with other models into unified access decisions.

Policy Engine

Central service for managing all authorization policies.

Policy Evaluation Model

How permission requests are evaluated and decisions produced.