Skip to main content

Attribute-Based Access Control (ABAC)

ABAC makes access decisions based on attributes of the user, resource, action, and environment. Unlike RBAC which relies on static role assignments, ABAC policies can evaluate dynamic conditions like time of day, IP address, user department, or resource ownership.

How ABAC Works​

An ABAC policy evaluates four categories of attributes:

CategoryExamples
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 /t/{tenantSlug}/portal/access-management/abac
  2. Click Create Policy
  3. Define the policy conditions:
FieldDescription
NameHuman-readable policy name
DescriptionWhat this policy controls
Subject ConditionsAttribute conditions on the user
Resource ConditionsAttribute conditions on the target resource
ActionThe action being controlled
Environment ConditionsContextual conditions
DecisionAllow or Deny
PriorityEvaluation order (higher priority wins on conflict)

Policy Evaluation​

When multiple policies match a request, the evaluation follows:

  1. All matching policies are collected
  2. Deny policies take precedence over Allow policies (deny-overrides)
  3. If no policies match, the default decision is Deny (closed-world assumption)

Subject Attributes​

User attributes available for ABAC conditions:

AttributeDescriptionExample
user.emailUser's email addressalice@acme.com
user.rolesAssigned roles["editor", "auditor"]
user.groupsGroup memberships["engineering"]
user.departmentDepartment field"engineering"
user.created_atAccount creation date2025-01-15
user.mfa_enabledWhether MFA is activetrue
user.email_verifiedEmail verification statustrue

Environment Attributes​

Contextual attributes evaluated at request time:

AttributeDescriptionExample
env.timeCurrent time14:30
env.day_of_weekCurrent daymonday
env.ip_addressRequest source IP192.168.1.100
env.countryGeoIP countryUS
env.device_typeDevice classificationdesktop
env.auth_methodHow the user authenticatedpasskey
env.risk_scoreAdaptive auth risk score25

Example Policies​

Restrict Sensitive Operations to MFA Users​

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

High-Risk Score Denial​

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

Combining ABAC with RBAC​

ABAC complements RBAC by adding contextual conditions. A common pattern:

  1. RBAC determines what a user can do (based on roles)
  2. ABAC determines when and where they can do it (based on context)

Example: An editor role grants documents:write, but an ABAC policy restricts writes to business hours from trusted IPs.

Testing Policies​

Use the Permission Tester at /t/{tenantSlug}/portal/access-management/permission-tester:

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