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

Create Policy

POST /api/admin/policies
Authorization: Bearer <admin_token>
Content-Type: application/json

{
  "id": "expense-approval",
  "description": "Expense approval policy",
  "effect": "allow",
  "target": {
    "resources": ["expenses"],
    "actions": ["approve"]
  },
  "condition": {
    "and": [
      { "subject.role": { "eq": "manager" } },
      { "resource.amount": { "lte": 10000 } }
    ]
  },
  "priority": 100
}

List Policies

GET /api/admin/policies
Authorization: Bearer <admin_token>

Evaluate Policy

POST /api/authorize
Authorization: Bearer <access_token>
Content-Type: application/json

{
  "action": "approve",
  "resource": {
    "type": "expenses",
    "id": "exp-123",
    "amount": 5000,
    "department": "engineering"
  },
  "subject": {
    "user_id": "user-456",
    "role": "manager",
    "department": "engineering"
  },
  "environment": {
    "time": "2024-01-15T10:30:00Z",
    "ip_address": "192.168.1.100"
  }
}

Response:

{
  "allowed": true,
  "decision": "permit",
  "policies_evaluated": ["expense-approval"],
  "reason": "Policy 'expense-approval' matched"
}

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