🔑 Chapter 9 — Access Control (Authorization) Cheat Sheet

🗺️ Big Picture

Access Control = Who can do What to Which resource
│
├── Core Concepts     → Subjects, Objects, Access Rights
├── 4 Policy Types    → DAC → MAC → RBAC → ABAC
│   ├── DAC           → Owner decides (Access Matrix, ACL, Capability List)
│   ├── MAC           → Security labels + clearances (Read Down / Write Up)
│   ├── RBAC          → Job roles (RBAC₀ → RBAC₃, SSD, DSD)
│   └── ABAC          → Attributes of user + resource + environment (XACML)
├── UNIX              → inodes, 12 protection bits
├── Least Privilege   → PoLP, Zero-Standing Privilege (ZSP)
└── ICAM              → Identity + Credential + Access Mgmt + Federation

1. Access Control Flow

User ──► Authentication Function ──► Access Control Function ──► System Resources
                                              ▲
Security Administrator ◄──► Authorization Database
                                              ▲
                                          Auditing

$\boxed{\text{Authentication = WHO you are} \quad \text{Authorization = WHAT you can do}}$

RFC 4949: Security = measures that implement and assure access control service.

2. Subjects, Objects, and Access Rights

Every access control decision involves these three: Subject → Access Right → Object

3. The Four Access Control Policies

4. Discretionary Access Control (DAC)

• Owner of a resource decides who can access it
• The owner is usually the creator of the resource

🗂️ Analogy: Like Google Drive — the file creator decides who can view or edit it.

Access Matrix

Two-dimensional table: rows = subjects, columns = objects, cells = permissions

Three Representations of the Same Data ⭐ Exam Note

อาจารย์ให้ Access Matrix มา อยากให้วาดเป็น ACL, Cap List ใน Final Exam!

(a) Access Control List (ACL) — per FILE, lists users with permissions

File 1 → A: Own/R/W,  B: R,         C: R/W
File 2 → B: Own/R/W,  C: R
File 3 → A: Own/R/W,  B: W
File 4 → B: R,        C: Own/R/W

🗃️ Analogy: A sign on the door listing who can enter and what they can do.

(b) Capability List — per USER, lists objects with permissions

User A → File 1: Own/R/W,  File 3: Own/R/W
User B → File 1: R,  File 2: Own/R/W,  File 3: W,  File 4: R
User C → File 1: R/W,  File 2: R,  File 4: Own/R/W

🎫 Analogy: A keychain — each user holds their own set of keys to specific files.

(c) Authorization Table — flat list of (Subject, Access Mode, Object) tuples

Every single permission is a row: e.g., A | Own | File 1, A | Read | File 1, B | Read | File 1 …

Extended Access Matrix

• Subjects can also be objects (e.g., $S_1$ has control over $S_2$)
• Adds process operations: wakeup, stop, execute
• Adds device operations: seek
• Copy flag (*) — permission marked with * can be transferred to others

5. Protection Domains

• A set of objects + access rights to those objects
• One row of the access matrix = one protection domain
• User can spawn processes with a subset of their own access rights

🏢 Analogy: Employee badge lets you into the lobby. Only IT badge opens the server room. Even with the server room access, you can't use equipment reserved for the sysadmin.

6. UNIX File Access Control

Inodes (Index Nodes)

• Every UNIX file has an inode storing: file attributes, permissions, control info
• Multiple file names can point to the same inode
• When a file is opened → inode loaded into main memory
• Directories = hierarchical tree containing file names + pointers to inodes

UNIX Permission Format — 12 Protection Bits

rw-  r--  ---
[Owner] [Group] [Other]

Three classes: Owner / Group / Other (World)

Example: rw-r-----

• Owner: Read + Write
• Group: Read only
• Other: No access

📚 Analogy: Library card system — owner can borrow and return books, group can only read in-library, others have no access.

7. Mandatory Access Control (MAC)

• Assigns a security level to all information
• Assigns a security clearance to each user
• Enforces access based on label vs. clearance comparison
• More secure than DAC — owner cannot override the policy

Read Down / Write Up Rules

$\boxed{\text{Read Down: clearance} \geq \text{classification} \Rightarrow \text{can read}}$ $\boxed{\text{Write Up: clearance} \leq \text{classification} \Rightarrow \text{can write}}$

🎖️ Analogy: A "Top Secret" cleared officer can read "Secret" documents, but cannot write to a "Classified" file — otherwise they'd be leaking data down the classification chain.

Security levels (example): Unclassified → Confidential → Secret → Top Secret

8. Role-Based Access Control (RBAC)

• Access based on assigned job role, not individual identity
• Roles defined by job functions: Accountant, IT Manager, CEO, Programmer, Tester, etc.
• Permissions defined by job authority and responsibilities

🏥 Analogy: Hospital — nurse can administer medication, doctor can prescribe, janitor cannot access patient records. When someone leaves their role → permissions automatically gone.

Key Advantage

$\boxed{\text{Users change frequently — Roles don't}}$

→ Assign users to roles, not permissions directly → massive reduction in admin overhead.

RBAC Model Family (RBAC₀ → RBAC₃)

$RBAC_0$ — Core RBAC

Entities:

Relationships:

• UA (User Assignment): many-to-many (user ↔ role)
• PA (Permission Assignment): many-to-many (role ↔ permission)
• user_session: one user → many sessions
• session_roles: roles activated in a session

$RBAC_1$ — Role Hierarchy

• Roles can inherit permissions from other roles
• General hierarchy — multiple inheritance (role can inherit from multiple parents)
• Limited hierarchy — one immediate descendant only

Cardiologist
    ↑ inherits from
Specialist
    ↑ inherits from
Doctor    Intern

$RBAC_2$ — Constraints (SSD & DSD)

Static Separation of Duty (SSD)

• User cannot be authorized for both conflicting roles — permanently
• Prevents conflict of interest at the authorization level

Example: A bank employee cannot hold both Teller AND Auditor roles.

Dynamic Separation of Duty (DSD)

• User cannot activate both conflicting roles in the same session
• Constraint enforced at runtime, not assignment level
• More operationally flexible than SSD

Example: A user can hold both Teller and Account Holder roles, but cannot act as both in the same session.

SSD vs. DSD Comparison

🚗 Analogy: SSD = You can never hold both a driver's license and a taxi permit. DSD = You can hold both, but can't use them at the same time.

RBAC Constraints

9. Least Privilege Principle (PoLP) ⭐ Exam Note

$\boxed{\text{Principle of Least Privilege (PoLP) = give only the minimum permissions needed for the task}}$

• Roles contain the minimum permissions to perform their function
• Users assigned to roles that allow only what's required
• No single role given more permission than necessary

Examples:

• A database retrieval account should NOT have admin rights
• A code developer should NOT have access to financial data

Zero-Standing Privilege (ZSP) ⭐⭐ Exam Note — Very Important!

$\boxed{\text{ZSP = No permanent admin rights — access granted on-demand and auto-revoked}}$

🏦 Analogy: Instead of giving a bank teller a permanent key to the vault, they request access before each shift → key expires when the shift ends → nobody can steal a key that doesn't exist.

10. Attribute-Based Access Control (ABAC)

• Access decisions based on attributes of user + resource + environment
• Fine-grained (individual level) vs. RBAC's coarse-grained (role level)
• Implemented via XACML (eXtensible Access Control Markup Language)
• Can enforce DAC, RBAC, and MAC concepts all in one system

🎯 Analogy: Instead of "nurses can access all patient records," ABAC says "a nurse from Ward-A can access records of patients in Ward-A only, during working hours, from a hospital device."

Four Attribute Types

How ABAC Works

Subject makes request
        ↓
Access Control Mechanism evaluates:
    ├── Access Control Policy (rules)
    ├── Subject Attributes
    ├── Object Attributes
    └── Environmental Conditions
        ↓
Decision: GRANT ✅ or DENY ❌
        ↓
Enforced on the Object

ABAC Policy Examples

Example 1 — Access Granted ✅

• Object: Type = "US Sales data"
• Subject: Department = "US Marketing"
• Environment: Location = "New York, US"
• Policy: "US Sales data accessible by US Marketing from a US location"
• → All attributes match → Access Granted

Example 2 — Access Denied ❌

• Object: Type = "US Sales data"
• Subject: Department = "US Marketing"
• Environment: Location = "London, UK"
• Policy: Same as above
• → Location doesn't match → Access Denied

RBAC vs. ABAC Comparison

11. ICAM — Identity, Credential, and Access Management

A comprehensive US government framework for managing digital identities, credentials, and access control.

Three Core Components

1. Identity Management

• Assigns attributes to a digital identity and connects it to an individual / NPE (Non-Person Entity)
• Goal: Establish a trustworthy digital identity independent of any specific application
• Lifecycle management includes:
  • Protecting personal identity information
  • Controlling access to identity data
  • Sharing authoritative identity data with applications
  • Revoking enterprise identities

2. Credential Management

A credential = object that authoritatively binds an identity to a token (e.g., smart card, private key, digital certificate)

5 Logical Components:

① Specify need for credential
② Credential Enrollment
③ Credential Generation
④ Credential Issuance
⑤ Maintenance

3. Access Management

• Manages how entities are granted access to resources (logical + physical)
• Three support elements:

Identity Federation

Technology, standards, policies, and processes allowing an organization to trust digital identities created by another organization.

$\boxed{\text{Identity Federation = Get ID Token from Identity Provider → Use that token to access multiple services}}$

🎓 Analogy: A university student ID accepted at a partner university library — you trust the other institution's verification process.

Flow:

User → Service Provider (SP) → Redirect Auth → Identity Provider (IdP)
                                                        ↓
                                               ID Token issued
                                                        ↓
                              Token used to access multiple services ✅

Real-World Examples:

• AWS IAM Federation
• Azure AD Federation
• Google Cloud Identity

Zero Trust Identity

$\boxed{\text{Zero Trust = Never trust, Always verify!}}$

Access decisions depend on: Identity + Device + Location + Behavior

Federation Attacks & Prevention

Future Directions of Identity Federation

• DID (Decentralized Identity)
• SSI (Self-Sovereign Identity)
• Blockchain-based identity systems

⚡ Key Facts to Remember