Authorization Models

Authorization is a critical aspect of security, defining what a user or system is allowed to do after successful authentication (verifying their identity). It’s the gatekeeper that ensures only authorized entities can access specific resources and perform certain actions. This post explores various authorization models, their strengths and weaknesses, and how they are implemented.

1. Role-Based Access Control (RBAC)

RBAC is the most widely adopted model. It assigns permissions to roles, and users are assigned to those roles. This simplifies management, as permissions are managed at the role level, rather than individually for each user.

Diagram:

flowchart TD
    subgraph Users[Users]
        U1[User 1]
        U2[User 2]
        U3[User 3]
    end

    subgraph Roles[Roles]
        Admin[Administrator]
        Manager[Manager]
        Staff[Staff]
    end

    subgraph Permissions[Permissions]
        P1[Create]
        P2[Read]
        P3[Update]
        P4[Delete]
    end

    subgraph Resources[Resources]
        R1[Files]
        R2[Applications]
        R3[Databases]
    end

    U1 -->|Assigned to| Admin
    U2 -->|Assigned to| Manager
    U3 -->|Assigned to| Staff

    Admin -->|Has| P1
    Admin -->|Has| P2
    Admin -->|Has| P3
    Admin -->|Has| P4

    Manager -->|Has| P1
    Manager -->|Has| P2
    Manager -->|Has| P3

    Staff -->|Has| P2

    P1 -->|Applies to| R1
    P1 -->|Applies to| R2
    P1 -->|Applies to| R3
    P2 -->|Applies to| R1
    P2 -->|Applies to| R2
    P2 -->|Applies to| R3
    P3 -->|Applies to| R1
    P3 -->|Applies to| R2
    P3 -->|Applies to| R3
    P4 -->|Applies to| R1
    P4 -->|Applies to| R2
    P4 -->|Applies to| R3

    style Admin fill:#ff9999
    style Manager fill:#99ff99
    style Staff fill:#9999ff
    style U1 fill:#f9f9f9
    style U2 fill:#f9f9f9
    style U3 fill:#f9f9f9
    style P1 fill:#ffe6cc
    style P2 fill:#ffe6cc
    style P3 fill:#ffe6cc
    style P4 fill:#ffe6cc

The diagram shows RBAC’s hierarchical structure:

1. Users are assigned to specific roles (Admin, Manager, Staff)
2. Roles have predefined permissions (Create, Read, Update, Delete)
3. Permissions apply to resources (Files, Applications, Databases)
4. Administrators have full CRUD access
5. Managers can create, read, and update
6. Staff members have read-only access

Strengths:

• Simplified management: Easier to manage permissions for large numbers of users.
• Granular control: Roles can be customized to precisely define permissions.
• Scalability: Well-suited for large organizations and complex systems.

Weaknesses:

• Role explosion: Too many roles can become difficult to manage.
• Inflexible: Difficult to handle exceptional cases that don’t fit neatly into roles.
• Static: Changes to roles often require system-wide updates.

2. Attribute-Based Access Control (ABAC)

ABAC is a more fine-grained model that uses attributes of the user, the resource, and the environment to determine access. This allows for highly dynamic and context-aware authorization decisions.

flowchart TD
    subgraph Inputs
        U[User Context]
        E[Environment Context]
        R[Resource Context]
        A[Action Type]
    end

    subgraph Attributes
        SA[Subject Attributes]
        EA[Environment Attributes]
        RA[Resource Attributes]
    end

    subgraph PolicyEngine
        P[Policy Rules]
        AE[Authorization Engine]
    end

    subgraph Decision
        D{Evaluation}
        P1[Permit]
        D1[Deny]
    end

    U --> SA
    E --> EA
    R --> RA
    
    SA --> AE
    EA --> AE
    RA --> AE
    A --> AE
    P --> AE
    
    AE --> D
    D -->|Allow| P1
    D -->|Reject| D1

    style U fill:#e6e6ff,stroke:#333
    style E fill:#e6e6ff,stroke:#333
    style R fill:#e6e6ff,stroke:#333
    style A fill:#e6e6ff,stroke:#333
    style AE fill:#d9d9ff,stroke:#333
    style P fill:#cce6ff,stroke:#333
    style P1 fill:#90EE90,stroke:#333
    style D1 fill:#FFB6C1,stroke:#333

The diagram shows:

1. Input Sources:
   • User Context (including attributes like age, name, role)
   • Environment Context (time, status, location)
   • Resource Context (classification, size, amount)
   • Action Type (read, delete, edit)
2. Attribute Processing:
   • Subject Attributes derived from User Context
   • Environment Attributes from Environment Context
   • Resource Attributes from Resource Context
3. Policy Engine:
   • Policy Rules defining access conditions
   • Authorization Engine that evaluates all inputs against policies
4. Decision Flow:
   • Evaluation node that determines the final outcome
   • Permit (green) and Deny (red) outcomes

The diagram follows the principle of eliminating redundancy by:

• Centralizing the authorization logic in a single engine
• Using attribute-based access control to avoid duplicating rules
• Standardizing the decision flow process

Strengths:

• Fine-grained control: Highly flexible and adaptable to changing requirements.
• Context-aware: Decisions based on user attributes, resource attributes, and environment conditions.
• Scalability: Can handle complex scenarios and large numbers of users and resources.

Weaknesses:

• Complexity: More complex to implement and manage than RBAC.
• Performance: Policy evaluation can be computationally expensive.
• Policy management: Requires complex policy management tools.

3. Access Control Lists (ACLs)

ACLs are a simple model where each resource has a list of users or groups and the permissions they have for that resource.

flowchart LR
    subgraph Users
        U1[User 1]
        U2[User 2]
        U3[User 3]
    end

    subgraph ACL["ACL Rules"]
        R1["Permit IP/Port"]
        R2["Deny IP/Port"]
    end

    subgraph Services
        S1[Email Port 443]
        S2[Gmail]
        S3[Other Services]
    end

    U1 --> R1
    U2 --> R1
    U3 --> R2
    
    R1 -->|Allow| S1
    R1 -->|Allow| S2
    R2 -->|Block| S3

    style U1 fill:#99ccff
    style U2 fill:#99ccff
    style U3 fill:#99ccff
    style R1 fill:#90EE90
    style R2 fill:#FFB6C1
    style S1 fill:#e6e6ff
    style S2 fill:#e6e6ff
    style S3 fill:#e6e6ff

The diagram shows ACL configuration with permit/deny rules controlling user access to network services. Green represents permitted access, red shows denied access, and blue indicates users and services.

Strengths:

• Simplicity: Easy to understand and implement.
• Direct access control: Explicitly defines permissions for each resource.

Weaknesses:

• Scalability: Difficult to manage for a large number of users and resources.
• Maintenance: Requires significant effort to manage changes in permissions.
• Lack of granularity: Limited ability to handle complex access scenarios.

4. Ownership-Based Access Control (OBAC)

OBAC is centered around the concept of ownership. The owner of a resource has full control over it, and can grant permissions to others. This is often combined with other models to provide a more effective system.

flowchart TD
    subgraph Users
        O[Owner]
        D[Delegated Users]
        R[Regular Users]
    end

    subgraph Resources
        Doc[Documents]
        Proj[Projects]
        Data[Data Sets]
    end

    subgraph Permissions
        Full[Full Control]
        Edit[Edit Rights]
        View[View Only]
    end

    O -->|Has| Full
    D -->|Granted| Edit
    R -->|Given| View

    Full -->|Complete Access| Doc
    Full -->|Complete Access| Proj
    Full -->|Complete Access| Data

    Edit -->|Modify| Doc
    Edit -->|Modify| Proj
    Edit -->|Modify| Data

    View -->|Read| Doc
    View -->|Read| Proj
    View -->|Read| Data

    O -->|Can Delegate| D

    style O fill:#ff9999
    style D fill:#99ff99
    style R fill:#9999ff
    style Full fill:#ff9999
    style Edit fill:#99ff99
    style View fill:#9999ff
    style Doc fill:#f9f9f9
    style Proj fill:#f9f9f9
    style Data fill:#f9f9f9

The diagram illustrates how Ownership-Based Access Control (OBAC) works:

1. User Hierarchy:

• Owners (red) have highest level access and can delegate rights
• Delegated users (green) receive edit permissions from owners
• Regular users (blue) have basic view access

2. Permission Levels:

• Full Control: Complete access to all resources
• Edit Rights: Ability to modify resources
• View Only: Read-only access

3. Resources Protected:

• Documents
• Projects
• Data Sets

4. Key Relationships:

• Owners can delegate permissions to other users
• Each permission level cascades to all resource types
• Users can only perform actions within their assigned permission level

This model emphasizes resource ownership as the basis for access control decisions, with clear hierarchical permissions structure.

Strengths:

• Intuitive: Simple to grasp and often aligns with users’ expectations.
• Simple implementation: Relatively straightforward to implement.

Weaknesses:

• Potential for conflicts: Can lead to conflicts if ownership is not clearly defined.
• Limited granularity: May not provide the fine-grained control needed in complex systems.