Attribute-Based Access Control

ABAC enables fine-grained access control by evaluating attributes of the subject, resource, action, and environment.

Overview

ABAC in Authrim allows you to:

• Define policies based on any attribute
• Support complex conditions with logical operators
• Make dynamic decisions based on context
• Implement domain-specific authorization logic

Core Concepts

Attributes

Attributes are the building blocks of ABAC policies:

Category	Examples
Subject	user_id, department, clearance_level, groups
Resource	type, owner, sensitivity, status
Action	read, write, delete, approve
Environment	time, ip_address, device_type, location

Policy Structure

{
  "id": "policy-001",
  "description": "Allow managers to approve expenses under $10,000",
  "effect": "allow",
  "target": {
    "resources": ["expenses"],
    "actions": ["approve"]
  },
  "condition": {
    "and": [
      { "subject.role": { "eq": "manager" } },
      { "resource.amount": { "lte": 10000 } }
    ]
  }
}

Policy Language

Comparison Operators

Operator	Description	Example
eq	Equal	{ "status": { "eq": "active" } }
ne	Not equal	{ "type": { "ne": "admin" } }
lt	Less than	{ "amount": { "lt": 100 } }
lte	Less than or equal	{ "age": { "lte": 18 } }
gt	Greater than	{ "score": { "gt": 80 } }
gte	Greater than or equal	{ "level": { "gte": 3 } }
in	In list	{ "department": { "in": ["sales", "marketing"] } }
contains	Contains substring	{ "email": { "contains": "@company.com" } }
startsWith	Starts with	{ "path": { "startsWith": "/api/" } }
endsWith	Ends with	{ "filename": { "endsWith": ".pdf" } }
matches	Regex match	{ "id": { "matches": "^[A-Z]{2}[0-9]+$" } }

Logical Operators

// AND - All conditions must be true
{
  "and": [
    { "subject.role": { "eq": "manager" } },
    { "resource.department": { "eq": "subject.department" } }
  ]
}

// OR - At least one condition must be true
{
  "or": [
    { "subject.role": { "eq": "admin" } },
    { "resource.owner": { "eq": "subject.id" } }
  ]
}

// NOT - Negates a condition
{
  "not": { "resource.status": { "eq": "archived" } }
}

Nested Conditions

{
  "and": [
    { "subject.authenticated": { "eq": true } },
    {
      "or": [
        { "subject.role": { "eq": "admin" } },
        {
          "and": [
            { "resource.owner": { "eq": "subject.id" } },
            { "resource.status": { "ne": "locked" } }
          ]
        }
      ]
    }
  ]
}

API Reference

Tenant Policy

GET /api/admin/tenant-policy
Authorization: Bearer <admin_token>

Update tenant policy with optimistic locking:

PUT /api/admin/tenant-policy
Authorization: Bearer <admin_token>
Content-Type: application/json

{
  "ifMatch": "3",
  "policy": {
    "metadata": { "status": "active" },
    "profile": "human"
  }
}

Available management endpoints:

Endpoint	Method	Description
/api/admin/tenant-policy	GET/PUT	Read or update the tenant contract policy
/api/admin/tenant-policy/presets	GET	List available presets
/api/admin/tenant-policy/apply-preset	POST	Apply a preset
/api/admin/tenant-policy/validate	GET	Validate the current tenant policy

Evaluate Policy

POST /policy/evaluate
Authorization: Bearer <policy_api_secret>
Content-Type: application/json

{
  "subject": {
    "id": "user-456",
    "roles": [{ "name": "manager", "scope": "global" }],
    "attributes": { "department": "engineering" }
  },
  "resource": {
    "type": "expenses",
    "id": "exp-123",
    "amount": 5000,
    "department": "engineering"
  },
  "action": "approve",
  "environment": {
    "time": "2024-01-15T10:30:00Z",
    "ip_address": "192.168.1.100"
  }
}

Response:

{
  "allowed": true,
  "reason": "Policy matched"
}

The policy worker endpoints are service-to-service APIs and require the internal policy API secret.

Policy Examples

Time-Based Access

{
  "id": "business-hours-only",
  "description": "Allow access only during business hours",
  "effect": "allow",
  "condition": {
    "and": [
      { "environment.hour": { "gte": 9 } },
      { "environment.hour": { "lt": 18 } },
      { "environment.weekday": { "in": [1, 2, 3, 4, 5] } }
    ]
  }
}

Resource Ownership

{
  "id": "owner-access",
  "description": "Allow owners full access to their resources",
  "effect": "allow",
  "condition": {
    "resource.owner": { "eq": "subject.id" }
  }
}

Multi-Level Approval

{
  "id": "high-value-approval",
  "description": "High-value expenses require director approval",
  "effect": "deny",
  "target": {
    "resources": ["expenses"],
    "actions": ["approve"]
  },
  "condition": {
    "and": [
      { "resource.amount": { "gt": 50000 } },
      { "subject.role": { "ne": "director" } }
    ]
  },
  "priority": 200
}

IP-Based Restrictions

{
  "id": "internal-only",
  "description": "Admin actions only from internal network",
  "effect": "deny",
  "target": {
    "actions": ["admin:*"]
  },
  "condition": {
    "not": {
      "environment.ip_address": { "startsWith": "10.0." }
    }
  }
}

Policy Evaluation

Decision Algorithm

1. Collect applicable policies - Match target (resource + action)
2. Evaluate conditions - Check each policy’s conditions
3. Apply combining algorithm - Determine final decision

Combining Algorithms

Algorithm	Description
Deny Override	If any policy denies, result is deny
Permit Override	If any policy permits, result is permit
First Applicable	First matching policy determines result
Priority-based	Highest priority matching policy wins

Default Decision

When no policy matches: Deny (secure by default)

Integration with RBAC

ABAC can reference role-based attributes:

{
  "condition": {
    "and": [
      { "subject.roles": { "contains": "manager" } },
      { "resource.department": { "eq": "subject.department" } }
    ]
  }
}

Best Practices

Policy Design

1. Start simple - Begin with basic policies, add complexity as needed
2. Use clear naming - Policy IDs and descriptions should be self-documenting
3. Test policies - Verify policies work as expected before deployment
4. Version policies - Track changes to policies over time

Performance

1. Minimize policy count - Fewer policies = faster evaluation
2. Use specific targets - Narrow down applicable policies
3. Cache decisions - Cache frequently evaluated decisions
4. Pre-compute attributes - Embed common attributes in tokens

Security

1. Default deny - Start with deny, explicitly allow
2. Audit decisions - Log authorization decisions
3. Review regularly - Audit policies periodically
4. Separation of concerns - Keep policy management separate from application code

References

• NIST ABAC Guide
• XACML 3.0