Computer NetworksSecurity Concepts

Fundamental Security Concepts

LevelIntermediate

Duration90 mins

TopicSecurity Concepts

3 / 5

Authorization: Controlling Access to Resources

From Identity to Permission

Authentication establishes who you are. Authorization determines what you can do. This distinction is fundamental: proving your identity is merely the first step. The second—and equally critical—step is determining which actions that identity may perform and which resources it may access.

Consider your experience with any enterprise system: You log in (authentication), but your experience differs vastly from your colleagues'. A developer sees code repositories and deployment pipelines. An accountant sees financial reports and invoices. A manager sees team performance metrics and approval queues. Same company, same login process, but completely different access—that's authorization at work.

Authorization is the enforcement mechanism of security policy. It translates organizational rules ("Employees see only their department's data") into technical controls (access control lists, role assignments, policy decisions). Get authorization wrong, and sensitive data leaks to unauthorized parties, privileged operations become available to attackers, and the entire security model collapses regardless of how robust authentication might be.

What You Will Learn

This page explores authorization comprehensively: the theoretical foundations of access control, major authorization models (DAC, MAC, RBAC, ABAC), policy specification and enforcement, common vulnerabilities, and modern authorization patterns including zero trust and policy-as-code approaches.

Authorization Fundamentals

The Core Question

Authorization answers: "Is this subject allowed to perform this action on this object?"

Every authorization decision involves three key elements:

Subject — The entity requesting access (user, process, service, device)
Object — The resource being accessed (file, database record, API endpoint, network segment)
Action — The operation being attempted (read, write, delete, execute, approve)

The Authorization Decision Process

Authorization decisions flow through multiple stages:

[Subject] --- requests ---> [Action on Object]
                                   |
                                   v
                          [Policy Decision Point]
                                   |
                         +---------+---------+
                         |         |         |
                         v         v         v
                      [Allow]  [Deny]  [Conditional]

Policy Decision Point (PDP): The component that evaluates access requests against policy rules and returns a decision.

Policy Enforcement Point (PEP): The component that intercepts access requests, queries the PDP, and enforces the decision.

Policy Information Point (PIP): Sources of attribute information (user groups, resource classifications, environmental context) used in authorization decisions.

Core Authorization Principles

•Principle of Least Privilege — Grant only the minimum permissions necessary for the task. Reduces blast radius of compromise.
•Separation of Duties — Critical operations require multiple parties, preventing unilateral action. No single person can approve and execute.
•Need-to-Know — Access based on operational necessity, not organizational hierarchy. Executives don't automatically access all data.
•Defense in Depth — Multiple authorization checkpoints. Application, database, and network each enforce access control.
•Fail-Secure (Default Deny) — When in doubt, deny access. Explicit grants required rather than explicit denials.
•Complete Mediation — Every access request must be checked. No caching that bypasses policy evaluation.

Authorization ≠ Authentication

These concepts are frequently confused but fundamentally different. You can be authenticated (identity proven) but unauthorized (not permitted access). You might authenticate as 'Bob' but lack authorization to access payroll data. Conversely, anonymous access policies might authorize actions without any authentication. Keep these concepts distinct in system design and troubleshooting.

Access Control Models

Access control models provide theoretical frameworks for organizing and enforcing authorization. Each model embodies different assumptions about who defines policy and how enforcement operates.

Discretionary Access Control (DAC)

In DAC, resource owners control access permissions at their discretion. The creator of a file decides who else may access it.

Characteristics:

Object owners set permissions
Permissions can be delegated to others
Users have autonomy over their own resources
No central policy authority enforces uniform rules

Implementation Examples:

Unix file permissions (owner/group/other)
Windows NTFS ACLs (Access Control Lists)
Share settings in cloud storage (Google Drive, Dropbox)

Advantages:

Flexible, supports diverse use cases
Users manage their own resources
Simple to understand conceptually

Disadvantages:

No global policy enforcement
Users may grant overly permissive access
Difficult to ensure consistent security across systems
Vulnerable to Trojan horse attacks (malicious programs inherit user's permissions)

Mandatory Access Control (MAC)

In MAC, a central authority defines access policy based on security classifications. Users cannot override these rules, regardless of object ownership.

Characteristics:

System-enforced policies that users cannot change
Security labels assigned to subjects and objects
Access decisions based on label comparisons
Primarily used in military and government systems

Security Models:

Bell-LaPadula (Confidentiality):

"No read up, no write down"
Subjects cannot read objects at higher classification
Subjects cannot write to objects at lower classification (prevents information flow down)

Biba (Integrity):

"No read down, no write up"
Subjects cannot read objects at lower integrity
Subjects cannot write to objects at higher integrity (prevents corruption flow up)

Implementation Examples:

SELinux (Security-Enhanced Linux)
AppArmor
Windows Mandatory Integrity Control
Classified government systems (Top Secret, Secret, Confidential)

Advantages:

Strong, consistent security guarantees
Users cannot accidentally or maliciously weaken security
Clear information flow control

Disadvantages:

Complex to administer
Can be inflexible for business needs
May impede legitimate work if policies are too restrictive

DAC vs. MAC Comparison
Aspect	Discretionary (DAC)	Mandatory (MAC)
Policy Authority	Resource owners	Central administration
User Autonomy	Users control their resources	Users cannot override policy
Flexibility	High (users adapt as needed)	Low (rigid policy structure)
Enforcement	Voluntary compliance	System-enforced, mandatory
Typical Use	Commercial systems, personal data	Military, government, high-security
Trojan Resistance	Vulnerable (inherits user rights)	Resistant (compartmentalized)

Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) bridges the gap between DAC flexibility and MAC structure. Permissions are assigned to roles, and users are assigned to roles. Users acquire permissions indirectly through their role memberships.

RBAC Core Concepts

Role: A collection of permissions that corresponds to a job function (e.g., "Developer," "Manager," "Auditor").

Permission: The ability to perform an action on a resource (e.g., "read:contracts," "deploy:production").

Role Assignment: Associating users with roles.

Role Hierarchy: Roles can inherit permissions from other roles (Senior Developer inherits from Developer).

RBAC0 - Basic RBAC

The foundational model with three components:

Users (subjects)
Roles (collections of permissions)
Permissions (action + object pairs)

User --> Role --> Permission --> Resource

Example:
Alice --> "Developer" --> ["read:code", "write:code", "run:tests"]
Bob --> "Manager" --> ["read:code", "read:reports", "approve:releases"]

RBAC1 - Role Hierarchies

Adds role inheritance: senior roles inherit permissions from junior roles.

         Senior Developer
               |
           Developer
           /       \
    Frontend Dev   Backend Dev

Senior Developer automatically has all permissions of Developer, which has permissions from both specialized roles.

RBAC2 - Constraints

Adds constraints that limit role assignments:

Static Separation of Duties (SSD): Mutually exclusive roles that cannot be assigned to the same user:

User cannot have both Purchaser and Approver roles
Prevents conflicts of interest

Dynamic Separation of Duties (DSD): Roles that cannot be activated simultaneously:

User can have both roles but cannot use both in the same session
Prevents self-dealing in single transactions

Cardinality Constraints:

Maximum users per role (only 3 people can be Super Admin)
Maximum roles per user (users can have at most 5 roles)

RBAC3 - Combined Model

Combines hierarchies (RBAC1) and constraints (RBAC2) for complete flexibility.

rbac-implementation
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
/**
 * RBAC Implementation Pattern
 * 
 * This demonstrates a clean RBAC implementation suitable
 * for application-level authorization.
 */
 
interface Permission {
  action: 'create' | 'read' | 'update' | 'delete' | 'execute';
  resource: string;
  conditions?: Record<string, unknown>; // Optional attribute conditions
}
 
interface Role {
  name: string;
  permissions: Permission[];
  inheritsFrom?: string[]; // Role hierarchy
}
 
interface User {
  id: string;
  roles: string[];
  attributes: Record<string, unknown>; // For ABAC-style conditions
}
 
class RBACAuthorizer {
  private roles: Map<string, Role> = new Map();
  
  /**
   * Register a role with its permissions
   */
  registerRole(role: Role): void {
    this.roles.set(role.name, role);
  }
  
  /**
   * Get all permissions for a role, including inherited
   */
  private getEffectivePermissions(roleName: string, visited = new Set<string>()): Permission[] {
    if (visited.has(roleName)) {
      return []; // Prevent circular inheritance
    }
    visited.add(roleName);
    
    const role = this.roles.get(roleName);
    if (!role) return [];
    
    // Start with direct permissions
    const permissions = [...role.permissions];
    
    // Add inherited permissions
    if (role.inheritsFrom) {
      for (const parentRole of role.inheritsFrom) {
        permissions.push(...this.getEffectivePermissions(parentRole, visited));
      }
    }
    
    return permissions;
  }
  
  /**
   * Check if a user is authorized for an action on a resource
   */
  isAuthorized(
    user: User, 
    action: Permission['action'], 
    resource: string,
    context?: Record<string, unknown>
  ): boolean {
    // Collect all permissions from all roles
    const allPermissions: Permission[] = [];
    
    for (const roleName of user.roles) {
      allPermissions.push(...this.getEffectivePermissions(roleName));
    }
    
    // Check if any permission matches
    return allPermissions.some(permission => {
      // Match action
      if (permission.action !== action) return false;
      
      // Match resource (supports wildcards)
      if (!this.matchResource(permission.resource, resource)) return false;
      
      // Evaluate conditions if present
      if (permission.conditions) {
        return this.evaluateConditions(permission.conditions, user, context);
      }
      
      return true;
    });
  }
  
  private matchResource(pattern: string, resource: string): boolean {
    // Support wildcard matching
    if (pattern === '*') return true;
    if (pattern.endsWith('*')) {
      return resource.startsWith(pattern.slice(0, -1));
    }
    return pattern === resource;
  }
  
  private evaluateConditions(
    conditions: Record<string, unknown>,
    user: User,
    context?: Record<string, unknown>
  ): boolean {
    // Simple condition evaluation
    // In production, use a policy engine like Open Policy Agent
    for (const [key, expected] of Object.entries(conditions)) {
      const actual = user.attributes[key] ?? context?.[key];
      if (actual !== expected) return false;
    }
    return true;
  }
}
 
// Example usage
const authorizer = new RBACAuthorizer();
 
// Define roles with hierarchy
authorizer.registerRole({
  name: 'viewer',
  permissions: [
    { action: 'read', resource: 'documents/*' }
  ]
});
 
authorizer.registerRole({
  name: 'editor',
  inheritsFrom: ['viewer'],
  permissions: [
    { action: 'create', resource: 'documents/*' },
    { action: 'update', resource: 'documents/*' }
  ]
});
 
authorizer.registerRole({
  name: 'admin',
  inheritsFrom: ['editor'],
  permissions: [
    { action: 'delete', resource: 'documents/*' },
    { action: 'read', resource: 'admin/*' },
    { action: 'update', resource: 'admin/*' }
  ]
});
 
// Check authorization
const user: User = {
  id: 'alice',
  roles: ['editor'],
  attributes: { department: 'engineering' }
};
 
console.log(authorizer.isAuthorized(user, 'read', 'documents/report.pdf'));   // true (inherited)
console.log(authorizer.isAuthorized(user, 'update', 'documents/report.pdf')); // true (direct)
console.log(authorizer.isAuthorized(user, 'delete', 'documents/report.pdf')); // false (admin only)

RBAC Best Practices

Keep roles aligned with job functions, not individual permissions. Create a role hierarchy that matches organizational structure. Avoid 'permission creep' by regularly reviewing role assignments. Use constraints (SSD/DSD) to enforce separation of duties. Document the purpose of each role to guide assignment decisions.

Attribute-Based Access Control (ABAC)

Attribute-Based Access Control (ABAC) provides the most flexible authorization model. Access decisions consider multiple attributes of subjects, objects, actions, and the environment—not just role membership.

ABAC Components

Subject Attributes: Properties of the requester

Department, clearance level, job title
Location, device type, authentication strength
Group memberships, certifications

Object Attributes: Properties of the resource

Classification level, data sensitivity
Owner, creation date, location
Document type, project association

Action Attributes: Properties of the requested operation

Read, write, delete, approve
Data volume, request frequency

Environment (Context) Attributes: Situational properties

Current time, date
Threat level, network location
Request origin, device security posture

ABAC Policy Example

Policy: "Doctors can view patient records during working hours from hospital devices, but only for patients they are treating."

policy ViewPatientRecords {
  subject.role == "doctor" AND
  object.type == "patient_record" AND
  subject.treatmentRelationship CONTAINS object.patientId AND
  environment.timeOfDay BETWEEN "07:00" AND "19:00" AND
  environment.deviceLocation == "hospital_network"
}

This policy references:

Subject attribute: role, treatmentRelationship
Object attribute: type, patientId
Environment attribute: timeOfDay, deviceLocation

ABAC Advantages

•Extremely flexible and expressive
•Context-aware decisions
•No role explosion problem
•Fine-grained access control
•Policies express business rules directly

ABAC Challenges

•Complex to implement correctly
•Policy maintenance can be difficult
•Harder to audit and understand
•Performance overhead from policy evaluation
•Requires reliable attribute sources

XACML: ABAC Standard

eXtensible Access Control Markup Language (XACML) is the OASIS standard for ABAC policy specification and evaluation.

XACML Architecture:

Policy Administration Point (PAP): Where policies are authored and managed
Policy Decision Point (PDP): Evaluates access requests against policies, returns decisions
Policy Enforcement Point (PEP): Intercepts requests, queries PDP, enforces decisions
Policy Information Point (PIP): Provides attribute values needed for decisions
Context Handler: Normalizes requests and communicates between components

XACML Decision Values:

Permit — Access allowed
Deny — Access denied
Indeterminate — Error or missing information
NotApplicable — No policy covers this request

Modern ABAC: Open Policy Agent (OPA)

OPA has emerged as the de facto standard for policy-as-code in cloud-native environments:

# OPA Policy in Rego language
package authorization

default allow = false

allow {
    input.method == "GET"
    input.path == ["documents", _]
    input.user.department == "engineering"
}

allow {
    input.method == "PUT"
    input.path == ["documents", doc_id]
    input.user.id == data.documents[doc_id].owner
}

RBAC vs. ABAC: When to Use Each

Use RBAC when access aligns with job functions and doesn't require dynamic conditions. Use ABAC when context matters (time, location, resource properties) or when policies are too nuanced for discrete roles. Many systems combine both: RBAC for basic structure plus ABAC for fine-grained refinement within roles.

Authorization Vulnerabilities

Authorization failures are among the most common and severe security vulnerabilities. OWASP consistently ranks Broken Access Control as a top web application risk.

Insecure Direct Object Reference (IDOR)

Occurs when an application exposes internal object identifiers without proper authorization checks:

Vulnerable Pattern:

GET /api/documents/12345  → Returns document 12345
GET /api/documents/12346  → Returns document 12346 (unauthorized!)

The application checks if the user is authenticated but doesn't verify they're authorized to access that specific document.

Mitigation:

Always verify the requesting user has permission to access the specific object
Use indirect references that map to object IDs only for authorized users
Implement consistent authorization checks in data access layer

Privilege Escalation

Vertical Escalation: Gaining higher privileges than assigned

Regular user accessing admin functions
Exploiting flaws to elevate from user to admin

Horizontal Escalation: Accessing resources of peers

User A accessing User B's data
Same privilege level, different authorization scope

Causes:

Missing authorization checks on sensitive functions
Role manipulation through parameter tampering
Session handling flaws that allow role switching

Common Authorization Vulnerabilities
Vulnerability	Description	Impact	Prevention
IDOR	Manipulating object references to access unauthorized data	Data breach, unauthorized access	Object-level authorization checks
Missing Function-Level Control	No authorization on administrative endpoints	Privilege escalation	Authorization on every endpoint
Parameter Tampering	Modifying role/permission parameters in requests	Privilege escalation	Server-side authorization, ignore client role claims
Path Traversal	Bypassing authorization via URL manipulation	Unauthorized file access	Canonicalize paths, enforce access control
JWT Manipulation	Modifying token claims to elevate privileges	Impersonation, escalation	Signature verification, server-side claims
Forced Browsing	Accessing unlinked but unprotected URLs	Information disclosure	Authorization on all resources

Broken Access Control Examples

Missing Authorization Check:

# VULNERABLE: No authorization check!
@app.route('/admin/users/<user_id>', methods=['DELETE'])
def delete_user(user_id):
    User.delete(user_id)
    return {'status': 'deleted'}

# SECURE: Verify admin role
@app.route('/admin/users/<user_id>', methods=['DELETE'])
@require_role('admin')  # Decorator enforces authorization
def delete_user(user_id):
    User.delete(user_id)
    return {'status': 'deleted'}

Client-Side Authorization (Dangerous):

// VULNERABLE: Authorization enforced only in UI
if (user.role === 'admin') {
    showAdminPanel();  // Attackers bypass this trivially
}

// SECURE: Server-side enforcement
// API returns 403 Forbidden for non-admins
// UI state reflects what server authorizes

Mass Assignment:

# VULNERABLE: Accepting all user-provided fields
@app.route('/profile', methods=['PUT'])
def update_profile():
    current_user.update(**request.json)  # Attacker sets {"role": "admin"}

# SECURE: Whitelist updatable fields
@app.route('/profile', methods=['PUT'])
def update_profile():
    allowed = ['name', 'email', 'avatar']
    updates = {k: v for k, v in request.json.items() if k in allowed}
    current_user.update(**updates)

Real-World Breach: 2019 First American Financial

First American Financial exposed 885 million sensitive documents—mortgage applications, social security numbers, bank statements—due to an IDOR vulnerability. Documents were accessible by simply changing the document ID in the URL. No authentication was required. Authorization checks existed for authenticated users but were completely absent for unauthenticated access. This single missing check exposed a decade of customer data.

Implementing Secure Authorization

Building robust authorization requires systematic design, consistent implementation, and continuous validation.

Design Principles

1. Centralize Authorization Logic

Don't scatter authorization checks throughout the codebase. Centralize in a policy service that all components consult:

                    ┌─────────────────────┐
                    │  Policy Decision    │
                    │     Point (PDP)     │
                    └──────────┬──────────┘
                               │
        ┌──────────┬───────────┼───────────┬──────────┐
        │          │           │           │          │
        ▼          ▼           ▼           ▼          ▼
   [API Gateway] [Service A] [Service B] [Service C] [UI]

2. Deny by Default

Implement fail-secure behavior: if authorization cannot be determined, deny access.

def check_authorization(user, resource, action) -> bool:
    try:
        return policy_engine.evaluate(user, resource, action)
    except Exception:
        log.error("Authorization decision failed - denying access")
        return False  # Fail secure

3. Layer Authorization Checks

Enforce authorization at multiple levels:

Network layer: Firewall rules, network segmentation
Application layer: API authorization, business logic checks
Database layer: Row-level security, view restrictions

Authorization Implementation Checklist

•Map all resources and operations — Identify every object that needs protection and every action that can be performed
•Define authorization policy — Document who can do what, under what conditions, in a format that developers can implement
•Implement centralized enforcement — Use middleware, decorators, or policy engines for consistent checks
•Verify at the data layer — Query only data the user is authorized to access; never filter unauthorized data after retrieval
•Test authorization boundaries — Include authorization bypass attempts in security testing
•Log authorization decisions — Record permits and denies for audit and incident response
•Review regularly — User roles and resource access evolve; ensure authorization keeps pace
•Handle edge cases — Deleted resources, suspended accounts, pending approvals need explicit policy

Data-Level Authorization

The most secure approach: filter unauthorized data at the query level, not in application code.

Insecure Pattern (Filter After Fetch):

-- Fetch ALL documents, then filter in code
SELECT * FROM documents;

-- Application code
filtered = [d for d in documents if d.owner_id == current_user.id]

Secure Pattern (Filter at Query):

-- Only fetch documents user is authorized to see
SELECT * FROM documents 
WHERE owner_id = :current_user_id 
   OR id IN (SELECT document_id FROM shared_access WHERE user_id = :current_user_id);

Row-Level Security (PostgreSQL):

-- Enable RLS on table
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- Policy: Users see only their documents and shared documents
CREATE POLICY user_document_access ON documents
  USING (
    owner_id = current_setting('app.current_user_id')::int
    OR id IN (
      SELECT document_id FROM shared_access 
      WHERE user_id = current_setting('app.current_user_id')::int
    )
  );

Policy as Code

Modern authorization increasingly treats policies as code—version controlled, tested, and deployed like application code. Tools like Open Policy Agent, Cedar, and Casbin enable this approach. Benefits include reproducibility, testability, auditability, and the ability to review policy changes just like code changes.

Modern Authorization Patterns

Microservices and API Authorization

Distributed systems complicate authorization: how do services authorize requests when they can't see the original user context?

JWT-Based Authorization:

Encoded claims flow with requests through the service mesh:

[User] ---(JWT)---> [API Gateway] ---(JWT)---> [Service A] ---(JWT)---> [Service B]

JWT Payload:
{
  "sub": "user123",
  "roles": ["editor"],
  "permissions": ["read:documents", "write:documents"],
  "tenant": "acme-corp",
  "exp": 1704067200
}

Each service validates the token signature and makes authorization decisions based on claims.

Limitations:

Tokens can be stolen and replayed
Claims are static until token expires
Large claim sets inflate token size
Revocation is difficult for stateless JWTs

Zero Trust Authorization

Zero Trust extends authorization beyond yes/no decisions to continuous, risk-based evaluation:

Principles:

Verify explicitly — Always authenticate and authorize based on all available data points
Use least privilege access — Limit access with just-in-time and just-enough-access
Assume breach — Minimize blast radius and segment access to contain compromises

Contextual Authorization Signals:

User identity and authentication strength
Device health and compliance status
Network location and connection security
Time and access patterns
Resource sensitivity classification
Threat intelligence indicators

Dynamic Access Decisions:

if (risk_score > threshold) {
    require_step_up_authentication();
}
if (device.compliance == 'non_compliant') {
    limit_access_to_low_sensitivity();
}
if (location == 'unknown' && time == 'unusual') {
    trigger_additional_verification();
}

Relationship-Based Authorization (ReBAC)

Authorization based on relationships between entities rather than static attributes:

// Google Zanzibar-style relationship tuples
document:report#viewer@user:alice
document:report#owner@user:bob
folder:engineering#member@group:engineers
group:engineers#member@user:alice

// Query: Can alice view report?
// Traverses: alice -> engineers -> engineering folder -> inherited viewer

ReBAC excels when access depends on how entities relate: file sharing, team membership, hierarchical resources.

Converting Mermaid diagram...

Summary: Authorization

Authorization—determining what authenticated entities may do—is essential for enforcing security policy. Without proper authorization, even perfect authentication leaves systems vulnerable. Let's consolidate the key concepts:

Key Takeaways

•Authorization answers 'What can you do?' — Distinct from authentication (who you are) and enforces access policy
•DAC provides flexibility, MAC provides control — Choose based on centralization needs and security requirements
•RBAC simplifies management — Role-based assignment with hierarchies and constraints suits most enterprise needs
•ABAC enables fine-grained control — Attribute-based decisions when context matters: time, location, resource properties
•IDOR and privilege escalation are critical vulnerabilities — Always check authorization at the object level
•Deny by default — Fail secure; explicit grants required; catch-all rules deny access
•Centralize and layer authorization — Consistent enforcement at network, application, and data layers
•Zero Trust continuously evaluates — Context-aware, risk-based authorization for modern security postures

What's Next:

With authentication (proving identity) and authorization (controlling access) established, we now explore Non-repudiation—the mechanisms that ensure entities cannot deny having performed actions, providing the accountability and auditability essential for security governance.

Page Complete

You now understand authorization in comprehensive depth—from theoretical access control models through practical implementation patterns and modern architectures. You can design authorization systems, identify vulnerabilities, and select appropriate models for different security requirements.

3 / 5

Loading learning content...

Computer NetworksSecurity Concepts

Fundamental Security Concepts

LevelIntermediate

Duration90 mins

TopicSecurity Concepts

3 / 5

Authorization: Controlling Access to Resources

From Identity to Permission

What You Will Learn

Authorization Fundamentals

The Core Question

Authorization answers: "Is this subject allowed to perform this action on this object?"

Every authorization decision involves three key elements:

Subject — The entity requesting access (user, process, service, device)
Object — The resource being accessed (file, database record, API endpoint, network segment)
Action — The operation being attempted (read, write, delete, execute, approve)

The Authorization Decision Process

Authorization decisions flow through multiple stages:

[Subject] --- requests ---> [Action on Object]
                                   |
                                   v
                          [Policy Decision Point]
                                   |
                         +---------+---------+
                         |         |         |
                         v         v         v
                      [Allow]  [Deny]  [Conditional]

Policy Decision Point (PDP): The component that evaluates access requests against policy rules and returns a decision.

Policy Enforcement Point (PEP): The component that intercepts access requests, queries the PDP, and enforces the decision.

Policy Information Point (PIP): Sources of attribute information (user groups, resource classifications, environmental context) used in authorization decisions.

Core Authorization Principles

•Principle of Least Privilege — Grant only the minimum permissions necessary for the task. Reduces blast radius of compromise.
•Separation of Duties — Critical operations require multiple parties, preventing unilateral action. No single person can approve and execute.
•Need-to-Know — Access based on operational necessity, not organizational hierarchy. Executives don't automatically access all data.
•Defense in Depth — Multiple authorization checkpoints. Application, database, and network each enforce access control.
•Fail-Secure (Default Deny) — When in doubt, deny access. Explicit grants required rather than explicit denials.
•Complete Mediation — Every access request must be checked. No caching that bypasses policy evaluation.

Authorization ≠ Authentication

Access Control Models

Access control models provide theoretical frameworks for organizing and enforcing authorization. Each model embodies different assumptions about who defines policy and how enforcement operates.

Discretionary Access Control (DAC)

In DAC, resource owners control access permissions at their discretion. The creator of a file decides who else may access it.

Characteristics:

Object owners set permissions
Permissions can be delegated to others
Users have autonomy over their own resources
No central policy authority enforces uniform rules

Implementation Examples:

Unix file permissions (owner/group/other)
Windows NTFS ACLs (Access Control Lists)
Share settings in cloud storage (Google Drive, Dropbox)

Advantages:

Flexible, supports diverse use cases
Users manage their own resources
Simple to understand conceptually

Disadvantages:

No global policy enforcement
Users may grant overly permissive access
Difficult to ensure consistent security across systems
Vulnerable to Trojan horse attacks (malicious programs inherit user's permissions)

Mandatory Access Control (MAC)

In MAC, a central authority defines access policy based on security classifications. Users cannot override these rules, regardless of object ownership.

Characteristics:

System-enforced policies that users cannot change
Security labels assigned to subjects and objects
Access decisions based on label comparisons
Primarily used in military and government systems

Security Models:

Bell-LaPadula (Confidentiality):

"No read up, no write down"
Subjects cannot read objects at higher classification
Subjects cannot write to objects at lower classification (prevents information flow down)

Biba (Integrity):

"No read down, no write up"
Subjects cannot read objects at lower integrity
Subjects cannot write to objects at higher integrity (prevents corruption flow up)

Implementation Examples:

SELinux (Security-Enhanced Linux)
AppArmor
Windows Mandatory Integrity Control
Classified government systems (Top Secret, Secret, Confidential)

Advantages:

Strong, consistent security guarantees
Users cannot accidentally or maliciously weaken security
Clear information flow control

Disadvantages:

Complex to administer
Can be inflexible for business needs
May impede legitimate work if policies are too restrictive

DAC vs. MAC Comparison
Aspect	Discretionary (DAC)	Mandatory (MAC)
Policy Authority	Resource owners	Central administration
User Autonomy	Users control their resources	Users cannot override policy
Flexibility	High (users adapt as needed)	Low (rigid policy structure)
Enforcement	Voluntary compliance	System-enforced, mandatory
Typical Use	Commercial systems, personal data	Military, government, high-security
Trojan Resistance	Vulnerable (inherits user rights)	Resistant (compartmentalized)

Role-Based Access Control (RBAC)

RBAC Core Concepts

Role: A collection of permissions that corresponds to a job function (e.g., "Developer," "Manager," "Auditor").

Permission: The ability to perform an action on a resource (e.g., "read:contracts," "deploy:production").

Role Assignment: Associating users with roles.

Role Hierarchy: Roles can inherit permissions from other roles (Senior Developer inherits from Developer).

RBAC0 - Basic RBAC

The foundational model with three components:

Users (subjects)
Roles (collections of permissions)
Permissions (action + object pairs)

User --> Role --> Permission --> Resource

Example:
Alice --> "Developer" --> ["read:code", "write:code", "run:tests"]
Bob --> "Manager" --> ["read:code", "read:reports", "approve:releases"]

RBAC1 - Role Hierarchies

Adds role inheritance: senior roles inherit permissions from junior roles.

         Senior Developer
               |
           Developer
           /       \
    Frontend Dev   Backend Dev

Senior Developer automatically has all permissions of Developer, which has permissions from both specialized roles.

RBAC2 - Constraints

Adds constraints that limit role assignments:

Static Separation of Duties (SSD): Mutually exclusive roles that cannot be assigned to the same user:

User cannot have both Purchaser and Approver roles
Prevents conflicts of interest

Dynamic Separation of Duties (DSD): Roles that cannot be activated simultaneously:

User can have both roles but cannot use both in the same session
Prevents self-dealing in single transactions

Cardinality Constraints:

Maximum users per role (only 3 people can be Super Admin)
Maximum roles per user (users can have at most 5 roles)

RBAC3 - Combined Model

Combines hierarchies (RBAC1) and constraints (RBAC2) for complete flexibility.

rbac-implementation
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
/**
 * RBAC Implementation Pattern
 * 
 * This demonstrates a clean RBAC implementation suitable
 * for application-level authorization.
 */
 
interface Permission {
  action: 'create' | 'read' | 'update' | 'delete' | 'execute';
  resource: string;
  conditions?: Record<string, unknown>; // Optional attribute conditions
}
 
interface Role {
  name: string;
  permissions: Permission[];
  inheritsFrom?: string[]; // Role hierarchy
}
 
interface User {
  id: string;
  roles: string[];
  attributes: Record<string, unknown>; // For ABAC-style conditions
}
 
class RBACAuthorizer {
  private roles: Map<string, Role> = new Map();
  
  /**
   * Register a role with its permissions
   */
  registerRole(role: Role): void {
    this.roles.set(role.name, role);
  }
  
  /**
   * Get all permissions for a role, including inherited
   */
  private getEffectivePermissions(roleName: string, visited = new Set<string>()): Permission[] {
    if (visited.has(roleName)) {
      return []; // Prevent circular inheritance
    }
    visited.add(roleName);
    
    const role = this.roles.get(roleName);
    if (!role) return [];
    
    // Start with direct permissions
    const permissions = [...role.permissions];
    
    // Add inherited permissions
    if (role.inheritsFrom) {
      for (const parentRole of role.inheritsFrom) {
        permissions.push(...this.getEffectivePermissions(parentRole, visited));
      }
    }
    
    return permissions;
  }
  
  /**
   * Check if a user is authorized for an action on a resource
   */
  isAuthorized(
    user: User, 
    action: Permission['action'], 
    resource: string,
    context?: Record<string, unknown>
  ): boolean {
    // Collect all permissions from all roles
    const allPermissions: Permission[] = [];
    
    for (const roleName of user.roles) {
      allPermissions.push(...this.getEffectivePermissions(roleName));
    }
    
    // Check if any permission matches
    return allPermissions.some(permission => {
      // Match action
      if (permission.action !== action) return false;
      
      // Match resource (supports wildcards)
      if (!this.matchResource(permission.resource, resource)) return false;
      
      // Evaluate conditions if present
      if (permission.conditions) {
        return this.evaluateConditions(permission.conditions, user, context);
      }
      
      return true;
    });
  }
  
  private matchResource(pattern: string, resource: string): boolean {
    // Support wildcard matching
    if (pattern === '*') return true;
    if (pattern.endsWith('*')) {
      return resource.startsWith(pattern.slice(0, -1));
    }
    return pattern === resource;
  }
  
  private evaluateConditions(
    conditions: Record<string, unknown>,
    user: User,
    context?: Record<string, unknown>
  ): boolean {
    // Simple condition evaluation
    // In production, use a policy engine like Open Policy Agent
    for (const [key, expected] of Object.entries(conditions)) {
      const actual = user.attributes[key] ?? context?.[key];
      if (actual !== expected) return false;
    }
    return true;
  }
}
 
// Example usage
const authorizer = new RBACAuthorizer();
 
// Define roles with hierarchy
authorizer.registerRole({
  name: 'viewer',
  permissions: [
    { action: 'read', resource: 'documents/*' }
  ]
});
 
authorizer.registerRole({
  name: 'editor',
  inheritsFrom: ['viewer'],
  permissions: [
    { action: 'create', resource: 'documents/*' },
    { action: 'update', resource: 'documents/*' }
  ]
});
 
authorizer.registerRole({
  name: 'admin',
  inheritsFrom: ['editor'],
  permissions: [
    { action: 'delete', resource: 'documents/*' },
    { action: 'read', resource: 'admin/*' },
    { action: 'update', resource: 'admin/*' }
  ]
});
 
// Check authorization
const user: User = {
  id: 'alice',
  roles: ['editor'],
  attributes: { department: 'engineering' }
};
 
console.log(authorizer.isAuthorized(user, 'read', 'documents/report.pdf'));   // true (inherited)
console.log(authorizer.isAuthorized(user, 'update', 'documents/report.pdf')); // true (direct)
console.log(authorizer.isAuthorized(user, 'delete', 'documents/report.pdf')); // false (admin only)

RBAC Best Practices

Attribute-Based Access Control (ABAC)

ABAC Components

Subject Attributes: Properties of the requester

Department, clearance level, job title
Location, device type, authentication strength
Group memberships, certifications

Object Attributes: Properties of the resource

Classification level, data sensitivity
Owner, creation date, location
Document type, project association

Action Attributes: Properties of the requested operation

Read, write, delete, approve
Data volume, request frequency

Environment (Context) Attributes: Situational properties

Current time, date
Threat level, network location
Request origin, device security posture

ABAC Policy Example

Policy: "Doctors can view patient records during working hours from hospital devices, but only for patients they are treating."

policy ViewPatientRecords {
  subject.role == "doctor" AND
  object.type == "patient_record" AND
  subject.treatmentRelationship CONTAINS object.patientId AND
  environment.timeOfDay BETWEEN "07:00" AND "19:00" AND
  environment.deviceLocation == "hospital_network"
}

This policy references:

Subject attribute: role, treatmentRelationship
Object attribute: type, patientId
Environment attribute: timeOfDay, deviceLocation

ABAC Advantages

•Extremely flexible and expressive
•Context-aware decisions
•No role explosion problem
•Fine-grained access control
•Policies express business rules directly

ABAC Challenges

•Complex to implement correctly
•Policy maintenance can be difficult
•Harder to audit and understand
•Performance overhead from policy evaluation
•Requires reliable attribute sources

XACML: ABAC Standard

eXtensible Access Control Markup Language (XACML) is the OASIS standard for ABAC policy specification and evaluation.

XACML Architecture:

Policy Administration Point (PAP): Where policies are authored and managed
Policy Decision Point (PDP): Evaluates access requests against policies, returns decisions
Policy Enforcement Point (PEP): Intercepts requests, queries PDP, enforces decisions
Policy Information Point (PIP): Provides attribute values needed for decisions
Context Handler: Normalizes requests and communicates between components

XACML Decision Values:

Permit — Access allowed
Deny — Access denied
Indeterminate — Error or missing information
NotApplicable — No policy covers this request

Modern ABAC: Open Policy Agent (OPA)

OPA has emerged as the de facto standard for policy-as-code in cloud-native environments:

# OPA Policy in Rego language
package authorization

default allow = false

allow {
    input.method == "GET"
    input.path == ["documents", _]
    input.user.department == "engineering"
}

allow {
    input.method == "PUT"
    input.path == ["documents", doc_id]
    input.user.id == data.documents[doc_id].owner
}

RBAC vs. ABAC: When to Use Each

Authorization Vulnerabilities

Authorization failures are among the most common and severe security vulnerabilities. OWASP consistently ranks Broken Access Control as a top web application risk.

Insecure Direct Object Reference (IDOR)

Occurs when an application exposes internal object identifiers without proper authorization checks:

Vulnerable Pattern:

GET /api/documents/12345  → Returns document 12345
GET /api/documents/12346  → Returns document 12346 (unauthorized!)

The application checks if the user is authenticated but doesn't verify they're authorized to access that specific document.

Mitigation:

Always verify the requesting user has permission to access the specific object
Use indirect references that map to object IDs only for authorized users
Implement consistent authorization checks in data access layer

Privilege Escalation

Vertical Escalation: Gaining higher privileges than assigned

Regular user accessing admin functions
Exploiting flaws to elevate from user to admin

Horizontal Escalation: Accessing resources of peers

User A accessing User B's data
Same privilege level, different authorization scope

Causes:

Missing authorization checks on sensitive functions
Role manipulation through parameter tampering
Session handling flaws that allow role switching

Common Authorization Vulnerabilities
Vulnerability	Description	Impact	Prevention
IDOR	Manipulating object references to access unauthorized data	Data breach, unauthorized access	Object-level authorization checks
Missing Function-Level Control	No authorization on administrative endpoints	Privilege escalation	Authorization on every endpoint
Parameter Tampering	Modifying role/permission parameters in requests	Privilege escalation	Server-side authorization, ignore client role claims
Path Traversal	Bypassing authorization via URL manipulation	Unauthorized file access	Canonicalize paths, enforce access control
JWT Manipulation	Modifying token claims to elevate privileges	Impersonation, escalation	Signature verification, server-side claims
Forced Browsing	Accessing unlinked but unprotected URLs	Information disclosure	Authorization on all resources

Broken Access Control Examples

Missing Authorization Check:

# VULNERABLE: No authorization check!
@app.route('/admin/users/<user_id>', methods=['DELETE'])
def delete_user(user_id):
    User.delete(user_id)
    return {'status': 'deleted'}

# SECURE: Verify admin role
@app.route('/admin/users/<user_id>', methods=['DELETE'])
@require_role('admin')  # Decorator enforces authorization
def delete_user(user_id):
    User.delete(user_id)
    return {'status': 'deleted'}

Client-Side Authorization (Dangerous):

// VULNERABLE: Authorization enforced only in UI
if (user.role === 'admin') {
    showAdminPanel();  // Attackers bypass this trivially
}

// SECURE: Server-side enforcement
// API returns 403 Forbidden for non-admins
// UI state reflects what server authorizes

Mass Assignment:

# VULNERABLE: Accepting all user-provided fields
@app.route('/profile', methods=['PUT'])
def update_profile():
    current_user.update(**request.json)  # Attacker sets {"role": "admin"}

# SECURE: Whitelist updatable fields
@app.route('/profile', methods=['PUT'])
def update_profile():
    allowed = ['name', 'email', 'avatar']
    updates = {k: v for k, v in request.json.items() if k in allowed}
    current_user.update(**updates)

Real-World Breach: 2019 First American Financial

Implementing Secure Authorization

Building robust authorization requires systematic design, consistent implementation, and continuous validation.

Design Principles

1. Centralize Authorization Logic

Don't scatter authorization checks throughout the codebase. Centralize in a policy service that all components consult:

                    ┌─────────────────────┐
                    │  Policy Decision    │
                    │     Point (PDP)     │
                    └──────────┬──────────┘
                               │
        ┌──────────┬───────────┼───────────┬──────────┐
        │          │           │           │          │
        ▼          ▼           ▼           ▼          ▼
   [API Gateway] [Service A] [Service B] [Service C] [UI]

2. Deny by Default

Implement fail-secure behavior: if authorization cannot be determined, deny access.

def check_authorization(user, resource, action) -> bool:
    try:
        return policy_engine.evaluate(user, resource, action)
    except Exception:
        log.error("Authorization decision failed - denying access")
        return False  # Fail secure

3. Layer Authorization Checks

Enforce authorization at multiple levels:

Network layer: Firewall rules, network segmentation
Application layer: API authorization, business logic checks
Database layer: Row-level security, view restrictions

Authorization Implementation Checklist

•Map all resources and operations — Identify every object that needs protection and every action that can be performed
•Define authorization policy — Document who can do what, under what conditions, in a format that developers can implement
•Implement centralized enforcement — Use middleware, decorators, or policy engines for consistent checks
•Verify at the data layer — Query only data the user is authorized to access; never filter unauthorized data after retrieval
•Test authorization boundaries — Include authorization bypass attempts in security testing
•Log authorization decisions — Record permits and denies for audit and incident response
•Review regularly — User roles and resource access evolve; ensure authorization keeps pace
•Handle edge cases — Deleted resources, suspended accounts, pending approvals need explicit policy

Data-Level Authorization

The most secure approach: filter unauthorized data at the query level, not in application code.

Insecure Pattern (Filter After Fetch):

-- Fetch ALL documents, then filter in code
SELECT * FROM documents;

-- Application code
filtered = [d for d in documents if d.owner_id == current_user.id]

Secure Pattern (Filter at Query):

-- Only fetch documents user is authorized to see
SELECT * FROM documents 
WHERE owner_id = :current_user_id 
   OR id IN (SELECT document_id FROM shared_access WHERE user_id = :current_user_id);

Row-Level Security (PostgreSQL):

-- Enable RLS on table
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- Policy: Users see only their documents and shared documents
CREATE POLICY user_document_access ON documents
  USING (
    owner_id = current_setting('app.current_user_id')::int
    OR id IN (
      SELECT document_id FROM shared_access 
      WHERE user_id = current_setting('app.current_user_id')::int
    )
  );

Policy as Code

Modern Authorization Patterns

Microservices and API Authorization

Distributed systems complicate authorization: how do services authorize requests when they can't see the original user context?

JWT-Based Authorization:

Encoded claims flow with requests through the service mesh:

[User] ---(JWT)---> [API Gateway] ---(JWT)---> [Service A] ---(JWT)---> [Service B]

JWT Payload:
{
  "sub": "user123",
  "roles": ["editor"],
  "permissions": ["read:documents", "write:documents"],
  "tenant": "acme-corp",
  "exp": 1704067200
}

Each service validates the token signature and makes authorization decisions based on claims.

Limitations:

Tokens can be stolen and replayed
Claims are static until token expires
Large claim sets inflate token size
Revocation is difficult for stateless JWTs

Zero Trust Authorization

Zero Trust extends authorization beyond yes/no decisions to continuous, risk-based evaluation:

Principles:

Verify explicitly — Always authenticate and authorize based on all available data points
Use least privilege access — Limit access with just-in-time and just-enough-access
Assume breach — Minimize blast radius and segment access to contain compromises

Contextual Authorization Signals:

User identity and authentication strength
Device health and compliance status
Network location and connection security
Time and access patterns
Resource sensitivity classification
Threat intelligence indicators

Dynamic Access Decisions:

if (risk_score > threshold) {
    require_step_up_authentication();
}
if (device.compliance == 'non_compliant') {
    limit_access_to_low_sensitivity();
}
if (location == 'unknown' && time == 'unusual') {
    trigger_additional_verification();
}

Relationship-Based Authorization (ReBAC)

Authorization based on relationships between entities rather than static attributes:

// Google Zanzibar-style relationship tuples
document:report#viewer@user:alice
document:report#owner@user:bob
folder:engineering#member@group:engineers
group:engineers#member@user:alice

// Query: Can alice view report?
// Traverses: alice -> engineers -> engineering folder -> inherited viewer

ReBAC excels when access depends on how entities relate: file sharing, team membership, hierarchical resources.

Converting Mermaid diagram...

Summary: Authorization

Key Takeaways

•Authorization answers 'What can you do?' — Distinct from authentication (who you are) and enforces access policy
•DAC provides flexibility, MAC provides control — Choose based on centralization needs and security requirements
•RBAC simplifies management — Role-based assignment with hierarchies and constraints suits most enterprise needs
•ABAC enables fine-grained control — Attribute-based decisions when context matters: time, location, resource properties
•IDOR and privilege escalation are critical vulnerabilities — Always check authorization at the object level
•Deny by default — Fail secure; explicit grants required; catch-all rules deny access
•Centralize and layer authorization — Consistent enforcement at network, application, and data layers
•Zero Trust continuously evaluates — Context-aware, risk-based authorization for modern security postures

What's Next:

Page Complete

3 / 5