Attribute-Based Access Control (ABAC)

ABAC evaluates attributes of the subject (the user), the resource, the action, and the environment (time, IP, device) against declarative policies. Unlike RBAC — which answers "does the user have role X?" — ABAC answers "do the facts about this request satisfy policy Y?". That lets you express rules like "engineering users can write to internal documents during business hours from trusted IPs" without baking role combinations into code.

Use ABAC when decisions depend on dynamic context. It pairs well with RBAC: role membership gates the capability, ABAC narrows it down with conditions.

---

How ABAC Works

An ABAC policy evaluates four attribute categories:

Category	Examples
Subject (who)	User role, department, clearance level, group membership
Resource (what)	Document classification, owner, creation date
Action (how)	Read, write, delete, approve
Environment (context)	Time of day, IP address, device type, location

Example Policy

"Allow users in the engineering group to write to internal documents during business hours (9 AM – 6 PM) from trusted IP ranges."

Subject:     group = "engineering"
Resource:    classification = "internal"
Action:      write
Environment: time between 09:00-18:00 AND ip in trusted_ranges
Decision:    ALLOW

---

Managing ABAC Policies

Create a Policy

1. Go to /orgs/{orgId}/portal/access-management/abac.
2. Click Create Policy.
3. Define the policy:

Field	Description
Name	Human-readable policy name
Description	What this policy controls
Subject Conditions	Attribute conditions on the user
Resource Conditions	Attribute conditions on the target resource
Action	The action being controlled
Environment Conditions	Contextual conditions
Decision	Allow or Deny
Priority	Evaluation order (higher priority evaluated first)

Policy Evaluation

LumoAuth combines policies using the deny-overrides algorithm:

1. Collect every policy whose action and resourceType match the request.
2. Evaluate each matching policy's conditions against the request attributes.
3. If any policy with decision: DENY matches, the final decision is Deny.
4. Otherwise, if at least one policy with decision: ALLOW matches, the final decision is Allow.
5. If no policy matches, the default is Deny (closed-world assumption).

Priority controls the order in which policies are considered, which is especially useful for ensuring restrictive deny policies are evaluated before broader allows.

---

Subject Attributes

Built-in user attributes available to conditions:

Attribute	Description	Example
user.email	User's email address	alice@acme.com
user.roles	Assigned roles	["editor", "auditor"]
user.groups	Group memberships	["engineering"]
user.department	Department field	"engineering"
user.created_at	Account creation date	2025-01-15
user.mfa_enabled	Whether MFA is active	true
user.email_verified	Email verification status	true

---

Environment Attributes

Contextual attributes evaluated at request time:

Attribute	Description	Example
env.time	Current time	14:30
env.day_of_week	Current day	monday
env.ip_address	Request source IP	192.168.1.100
env.country	GeoIP country	US
env.device_type	Device classification	desktop
env.auth_method	How the user authenticated	passkey
env.risk_score	Adaptive auth risk score	25

---

Example Policies

Require MFA for Sensitive Actions

Name:        Require MFA for sensitive actions
Subject:     user.mfa_enabled = false
Action:      delete, approve
Decision:    DENY

Geographic Restriction

Name:        Allow access only from US
Environment: env.country != "US"
Decision:    DENY

Business Hours Only

Name:        Allow write access during business hours
Action:      write
Environment: env.time >= 09:00 AND env.time <= 18:00
             AND env.day_of_week in ["monday","tuesday","wednesday","thursday","friday"]
Decision:    ALLOW

Block High-Risk Sessions

Name:        Block high-risk sessions
Environment: env.risk_score >= 80
Decision:    DENY

---

Combining ABAC with RBAC

ABAC complements RBAC. A common pattern:

1. RBAC decides what a user can do based on their roles.
2. ABAC decides when and where they can do it based on context.

Example: the editor role grants documents:write, and an ABAC policy limits documents:write to business hours from trusted IPs.

---

Testing Policies

Use the Permission Tester at /orgs/{orgId}/portal/access-management/permission-tester:

1. Select a user.
2. Specify the resource and action.
3. Set environment context (time, IP, etc.).
4. Review which policies match and the resulting decision.
5. Debug policy conflicts.

---

Related

• Roles & Permissions — base RBAC model.
• Zanzibar — relationship-based access.
• AI Policy Authoring — generate ABAC policies from plain English.
• Adaptive MFA — risk scores as ABAC attributes.