Authorisation Pattern

Authorisation Security Pattern

Ensures entities can only perform actions they are permitted to perform on resources they are permitted to access. Prevents privilege escalation and unauthorized access.

Problem Addressed

Entity performs disallowed action: An unprivileged user performs actions reserved for administrators, accesses other users' data, or manipulates resources beyond their permissions.

Examples:

• User changes another customer's account details
• Unprivileged entity performs admin operations
• Attacker accesses internal documents by guessing identifiers

Core Components

Data Elements

• action: Operation Subject wants to perform
• principal: Authenticated identity of Subject
• actionId: Identifier for the action type
• objectId: Identifier for the target resource
• privileges: Permissions granted to principal

Authorisation Flow

Subject → [action(principal)] → Enforcer
Enforcer → [authorise(principal, actionId, objectId)] → Decider
Decider → [get_privileges(principal)] → Policy Provider
Policy Provider → [privileges] → Decider
Decider → [allowed/denied] → Enforcer
Enforcer → [action] → System (if allowed)
        → [error] → Subject (if denied)

1. Subject (with established principal) requests action
2. Enforcer intercepts and extracts actionId, objectId
3. Decider queries Policy Provider for privileges
4. Decider evaluates request against privileges
5. If allowed: forward to System
6. If denied: return error to Subject

Critical Considerations

Authorise After Authentication

• Enforcer must only process authenticated requests
• Principal must be established before authorization
• Combine with Authentication pattern

Default Deny

• Deny all requests unless explicitly allowed
• Policy should grant permissions, not revoke them
• Missing rule = denied

Object-Level Authorization (IDOR Prevention)

Critical: Always check both:

1. Can principal perform this ACTION type?
2. Can principal access this specific OBJECT?

Failing to check objectId leads to Insecure Direct Object Reference (IDOR) vulnerabilities.

Complete Mediation

• Check EVERY request
• No bypass paths
• Enforcer must be unavoidable

Policy Integrity

• Protect policy from unauthorized modification
• Policy changes = security-sensitive operations
• Audit policy modifications

Resource Concerns

• Enforcer/Decider on every request path
• Potential performance bottleneck
• Potential DoS target
• Consider caching, rate limiting

Authorization Models

Role-Based Access Control (RBAC)

Principal → Roles → Permissions

• Assign roles to users
• Assign permissions to roles
• Check if principal's roles include required permission

Attribute-Based Access Control (ABAC)

if (subject.dept == resource.dept AND
    subject.clearance >= resource.classification)
    then allow

• Evaluate attributes of subject, resource, environment
• Flexible policy expressions

Access Control Lists (ACL)

Resource → [allowed principals/operations]

• Per-resource permission lists
• Direct mapping of who can do what

Implementation Checklist

• Authentication precedes authorization
• Default deny policy
• Action-level authorization check
• Object-level authorization check (IDOR prevention)
• Enforcer cannot be bypassed
• Policy protected from tampering
• Policy changes audited
• Consistent error messages (no information leakage)
• Rate limiting on authorization endpoints

Error Handling

Return consistent errors:

• Don't reveal whether resource exists
• Don't reveal why authorization failed specifically
• Log details server-side, return generic errors to client

Related Patterns

• Authentication (establishes principal)
• Session-based access control (combines both)
• Log entity actions (audit trail)
• Limit request rate (DoS protection)

References

• Source: https://securitypatterns.distrinet-research.be/patterns/
• OWASP Authorization Cheat Sheet
• OWASP IDOR Prevention