After completing this tutorial, you should be able to:
In previous tutorials, we have focused on authentication—the process of verifying who an entity is. However, authentication alone does not guarantee security. Once a user or system is authenticated, we must determine what they are allowed to do. This is the domain of access control. Access control is the mechanism that enforces the security policy by regulating who can access what resources and in what manner.
Access control is one of the most fundamental and critical components of any security architecture. It protects the confidentiality, integrity, and availability of information and systems by ensuring that only authorized subjects can perform authorized actions on authorized objects. Without effective access control, even the strongest authentication mechanisms are rendered useless—an attacker who can bypass authentication or misuse legitimate credentials can cause significant damage.
This tutorial provides a comprehensive introduction to access control fundamentals. We begin by defining the core concepts: subjects (active entities that request access), objects (passive entities that are accessed), and permissions (the allowed operations). We also discuss the related concepts of rights, privileges, and authorization.
We then explore the role of security policies in access control—the formal statements that specify the rules for access. We examine fundamental security principles such as least privilege, separation of duties, need-to-know, and defense in depth, and how they guide the design of access control systems.
A major focus is on the four primary access control models: Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC). We provide an overview of each model, its underlying philosophy, advantages, limitations, and typical use cases. These models will be examined in much greater depth in subsequent tutorials (3.10–3.12).
We also discuss the mechanisms that implement access control, including Access Control Lists (ACLs), capability lists, and the architectural pattern of Policy Decision Points (PDP) and Policy Enforcement Points (PEP). We explore the administrative aspects of access control, including user provisioning, privilege management, access reviews, and auditing.
Finally, we touch on trusted computing concepts—the principles and technologies that ensure that access control mechanisms themselves are reliable and cannot be subverted. We examine the concept of a Trusted Computing Base (TCB) and the importance of secure system design.
The tutorial concludes with two case studies: one illustrating the implementation of access control in a healthcare setting (HIPAA compliance), and another looking at a cloud infrastructure access control strategy. These examples demonstrate the practical application of the concepts covered.
By the end of this tutorial, you will have a solid foundation in access control principles and models, enabling you to design, evaluate, and implement access control solutions in a variety of contexts. This foundation is essential for the deeper explorations of DAC, MAC, RBAC, and ABAC that follow in Tutorials 3.10–3.12.
Access control is the process of determining and enforcing who is allowed to access what resources and under what conditions. It is a core security function that protects information and system resources from unauthorized access, modification, destruction, or misuse. Access control is often described as the "gatekeeper" that stands between authenticated users and the assets they wish to use.
Access control is distinct from authentication, though they work together. Authentication establishes the identity of the entity (subject). Access control then uses that identity (and possibly other attributes) to decide what that entity is permitted to do. The combination of authentication and access control is often referred to as authorization—the process of granting or denying permissions.
Access control is defined by three fundamental elements:
An access decision is the outcome of evaluating a request against the access control policy. The decision is typically either permit or deny, though some systems may return conditional decisions (e.g., "permit with audit"). The decision is made by a policy decision point (PDP) and enforced by a policy enforcement point (PEP).
Figure 1: Access control decision flow with PDP and PEP.
A subject is any entity that can request access to a resource. Subjects are typically users, but can also be processes, applications, devices, or even other systems. In many security models, subjects are associated with an identity (e.g., a username or user ID) that is established during authentication.
Subjects can be classified into different types based on their level of trust or privilege. For example, a system may have regular users, administrators, and guest accounts. Subjects can also have attributes such as roles, group memberships, or security clearances that influence access decisions.
An object is a passive entity that contains or receives information or resources. Objects can be concrete (e.g., a file, a printer, a database table) or abstract (e.g., a network service, a memory segment, a process). Each object has a set of permissions that define what operations can be performed on it.
Objects are often organized hierarchically (e.g., directories containing files, databases containing tables) to facilitate inheritance of permissions. For example, a user with read access to a directory may inherit read access to all files within that directory, unless explicitly overridden.
Permissions (also called rights or privileges) define the operations that a subject is allowed to perform on an object. Common permission types include:
The set of permissions varies by object type and system. For example, a file system typically uses read, write, and execute permissions; a printer might have print, manage, and queue permissions; a database might have select, insert, update, delete.
The access control matrix is a conceptual model that represents the permissions of all subjects on all objects. It is a two-dimensional table where rows represent subjects and columns represent objects, and each cell contains the permissions that the subject has on that object.
The access control matrix is not typically implemented directly in practice due to scalability issues, but it is a useful theoretical framework. It illustrates the relationship between subjects, objects, and permissions.
| Subject \ Object | File A | File B | Directory X |
|---|---|---|---|
| Alice | Read, Write | Read | List, Create |
| Bob | Read | Read, Write, Delete | List |
| Admin | Read, Write, Delete, Change | Read, Write, Delete, Change | Full Control |
Table 1: Example access control matrix.
An access control policy is a set of rules that governs how subjects are allowed to access objects. It is a formal statement of the security requirements for a system. The policy defines what is permitted and what is forbidden, and it is the foundation on which access control mechanisms are built.
Policies can be expressed in various ways: high-level natural language statements, formal mathematical models, or machine-readable policy languages (e.g., XACML, OAuth scopes). The policy must be consistent, unambiguous, and enforceable.
Access control policies are enforced by mechanisms that intercept access requests and make decisions. The two primary architectural components are:
This separation of decision and enforcement allows for centralized policy management and consistent enforcement across diverse systems.
An access control model is a formal framework for defining and enforcing access control policies. Different models offer different approaches to specifying who can access what and under what conditions. The four major models are DAC, MAC, RBAC, and ABAC. Each has its own philosophy, advantages, and limitations, and they are often used in combination.
In DAC, the owner of an object has discretion over who can access it and with what permissions. The owner can grant permissions to other subjects at their discretion. DAC is intuitive and flexible, making it the most common model in desktop and file systems (e.g., UNIX permissions, NTFS).
Advantages: Flexible, easy to understand, suitable for personal and small-group environments. Limitations: Can lead to inconsistent policies, does not scale well, and is vulnerable to Trojan horse attacks because users can grant permissions that propagate malware.
In MAC, access decisions are made by a central authority (the system) based on fixed security labels assigned to subjects and objects. Subjects and objects are assigned classification levels (e.g., Top Secret, Secret, Confidential, Unclassified). Access is allowed only if the subject's clearance is at least the object's classification and the subject has appropriate rights. MAC is used in high-security environments (military, government).
Advantages: Strong, centralized control, resistant to user errors, enforces strict information flow. Limitations: Rigid, requires careful labeling, not suitable for dynamic or collaborative environments.
RBAC assigns permissions to roles rather than to individual users. Users are assigned to roles based on their job functions. Permissions are granted to roles, and users inherit the permissions of the roles they belong to. RBAC simplifies administration by aligning permissions with organizational structure.
Advantages: Scalable, manageable, supports least privilege and separation of duties through role hierarchies and constraints. Limitations: May not capture fine-grained or context-dependent permissions; role explosion can occur in large organizations.
ABAC makes access decisions based on attributes of the subject, object, environment, and requested action. Attributes are key-value pairs that describe properties (e.g., user department, object classification, time of day). Policies are expressed in terms of attributes, allowing for highly dynamic and fine-grained access control.
Advantages: Highly flexible, supports dynamic and context-aware decisions, suitable for distributed and cloud environments. Limitations: Complex to design and manage, performance overhead, requires attribute management infrastructure.
| Model | Decision Basis | Administration | Scalability | Typical Use Cases |
|---|---|---|---|---|
| DAC | Owner discretion | Decentralized | Low to medium | File systems, personal devices |
| MAC | Security labels (clearance/classification) | Centralized | High (with labeling) | Military, government, high-security |
| RBAC | Role membership | Centralized role management | High | Enterprise applications, ERP, CRM |
| ABAC | Subject/object/environment attributes | Centralized policy engine | High (with attribute management) | Cloud IAM, IoT, multi-tenant systems |
An Access Control List (ACL) is a list attached to an object that specifies which subjects have which permissions on that object. Each entry in the ACL typically contains a subject identifier (user or group) and a set of permissions. ACLs are the most common implementation of DAC.
Example: A file might have an ACL that allows Alice read/write, Bob read, and the Administrators group full control.
A capability list is a list attached to a subject that specifies which objects the subject can access and with which permissions. This is the inverse of an ACL. Capabilities are often used in distributed systems and capability-based security models. They are more difficult to administer at scale, but they offer advantages in delegation and revocation.
Policy-based access control uses a central policy engine (PDP) to make decisions based on policies expressed in a high-level language. XACML (eXtensible Access Control Markup Language) is a standard for such policies. PBAC is often combined with ABAC to provide dynamic, context-aware decisions.
RBAC is implemented by assigning users to roles and roles to permissions. ABAC uses policies that evaluate attributes to make decisions. Both can be supported by central policy engines and directory services.
The administration of access control involves:
Enforcing separation of duties often involves defining conflicting roles (e.g., a user cannot be both a purchase requester and an approver). Access control systems should enforce SoD rules during role assignment.
Organizations must demonstrate compliance with regulations (e.g., HIPAA, GDPR, SOX) through access control policies and audit trails. Reporting tools generate evidence that access is appropriately controlled.
The Trusted Computing Base (TCB) is the set of all hardware, software, and firmware components that are critical to the security of a system. It includes the components that enforce the security policy, such as the kernel, access control mechanisms, and authentication modules. The TCB must be trusted to be correct and secure.
A security kernel is a small, trusted component of the TCB that mediates all access requests. It implements the reference monitor concept—a trusted mechanism that validates every request against the security policy. The reference monitor must be tamper-proof, always invoked, and small enough to be subject to formal verification.
Trusted computing relies on assurance—the degree of confidence that the system meets its security requirements. Evaluation criteria such as the Common Criteria (ISO 15408) provide a framework for assessing the security of IT products, including access control mechanisms.
Background: A hospital uses an Electronic Health Record (EHR) system that must comply with HIPAA regulations, which require strict access controls to patient data. The system must ensure that only authorized healthcare providers can access patient records, and only for legitimate treatment purposes.
Solution:
Outcome: The system meets HIPAA compliance, ensures patient privacy, and provides audit trails.
Background: A company uses AWS to host its applications. They need to control access to AWS resources (EC2 instances, S3 buckets, databases) for developers, DevOps engineers, and administrators.
Solution:
Outcome: The company achieves fine-grained, dynamic access control with audit trails for compliance.
This tutorial provided a comprehensive introduction to the fundamentals of access control. We defined the core concepts of subjects, objects, and permissions, and introduced the access control matrix as a theoretical model. We discussed the importance of security policies and the guiding principles of least privilege, separation of duties, need-to-know, and defense in depth.
We provided an overview of the four major access control models: Discretionary (DAC), Mandatory (MAC), Role-Based (RBAC), and Attribute-Based (ABAC). We compared their philosophies, advantages, and limitations, and discussed their typical use cases. We also explored the mechanisms that implement access control, including ACLs, capabilities, and policy decision/enforcement points.
The tutorial covered the administrative aspects of access control—provisioning, privilege management, access reviews, and auditing—and introduced trusted computing concepts such as the TCB, security kernel, and reference monitor. Two case studies illustrated how these concepts are applied in healthcare and cloud infrastructure environments.
This foundational tutorial sets the stage for the deeper examinations of each access control model in the tutorials that follow. In Tutorial 3.10, we will dive into Discretionary Access Control (DAC), exploring its implementation, advantages, and vulnerabilities. We will also look at Access Control Lists (ACLs) and capability lists in detail.
Answer the following questions to check your understanding. Click the "Answer" button to reveal the solution.
Q1. In access control terminology, a subject is:
Q2. Which access control model allows the owner of a file to grant permissions to other users?
Q3. The principle of "least privilege" means:
Q4. An Access Control List (ACL) is attached to:
Q5. Which access control model uses security labels (clearance and classification) to enforce policy?
Q6. In RBAC, permissions are assigned to:
Q7. Which component makes the access decision based on the policy?
Q8. The Trusted Computing Base (TCB) includes:
Q9. Separation of duties (SoD) is primarily intended to prevent:
Q10. An access control policy is:
Q11. Which model is most suitable for a dynamic, cloud-based environment with many attributes?
Q12. The reference monitor concept is associated with:
These exercises are designed to help you apply the concepts from this tutorial. Attempt each exercise before revealing the sample solution.
Exercise 3.9-1: Access Control Matrix
Consider a system with three users: Alice, Bob, and Charlie. There are three objects: File1, File2, and Printer1. Define permissions as Read, Write, and Print (for Printer1). Create an access control matrix that satisfies the following policies:
Then, convert this matrix into an ACL for each object and a capability list for each user.
Access Control Matrix:
| Subject \ Object | File1 | File2 | Printer1 |
|---|---|---|---|
| Alice | Read, Write | Read | (none) |
| Bob | Read | (none) | |
| Charlie | (none) | Write |
ACLs (attached to objects):
Capability Lists (attached to subjects):
Exercise 3.9-2: Security Principles Analysis
For each of the following scenarios, identify which security principle(s) are being violated and explain why.
Exercise 3.9-3: Model Selection
You are designing an access control system for a large university with 30,000 students and 5,000 faculty/staff. The university wants to control access to a learning management system, library resources, and administrative applications. Propose an appropriate access control model and justify your choice. Discuss the advantages and limitations of your chosen model in this context.
Recommendation: Role-Based Access Control (RBAC) with some attribute extensions.
Justification: The university has well-defined roles: students, faculty, staff, administrators. Each role has specific permissions (e.g., students can view courses and submit assignments; faculty can create courses and grade; staff manage enrollment). RBAC aligns with the organizational structure and simplifies administration. Attribute extensions (e.g., department, semester, student status) can provide finer control.
Advantages: Scalable to large user populations; easy to manage via role assignments; supports least privilege.
Limitations: May not capture all dynamic permissions (e.g., temporary access to a project); role explosion if too many roles are defined.
Alternative: ABAC could also be used, but may be overkill for this scenario; RBAC with attributes strikes a good balance.
Exercise 3.9-4: PDP/PEP Architecture
Design a PDP/PEP architecture for a file-sharing service. Describe the components, how requests are processed, and how policies are stored and managed. Include a flow diagram.
Components:
Flow:
Diagram: (Similar to Figure 1 in the tutorial)
Exercise 3.9-5: Policy Analysis
Given the following access control policy for a hospital system, identify potential weaknesses and propose improvements.
Policy: "All doctors can access all patient records. Nurses can view patient records only for patients in their unit. Administrative staff can view billing information but not clinical data. Emergency access is allowed."
Consider issues such as least privilege, separation of duties, and auditability.
Weaknesses:
Improvements:
These homework questions require deeper analysis, research, and application. Answer each question comprehensively.
Homework 3.9-1: Access Control Models Research
Write a 1,000–1,250 word research paper comparing the four major access control models (DAC, MAC, RBAC, ABAC). For each model, describe its core principles, strengths, weaknesses, and typical use cases. Provide a detailed example for each model in a specific context (e.g., DAC in file systems, MAC in government, RBAC in enterprise applications, ABAC in cloud IAM). Discuss the factors that influence the choice of a model for an organization.
Comparative Analysis of Access Control Models
Homework 3.9-2: Security Policy Design
Design a comprehensive access control policy for a financial institution that handles sensitive customer data and must comply with regulations (e.g., GLBA, SOX). The policy should specify:
Provide a detailed policy document.
Access Control Policy – Financial Institution
Homework 3.9-3: Trusted Computing and Evaluation
Write a 750–1,000 word essay on the importance of the Trusted Computing Base (TCB) and the reference monitor concept in secure access control. Discuss how the Common Criteria (ISO 15408) evaluates security products and what assurance levels mean. Provide examples of how a secure operating system might implement a TCB.
Trusted Computing and Access Control Assurance
Homework 3.9-4: Access Control Implementation Analysis
Select a real-world access control system (e.g., Windows NTFS, Linux file permissions, AWS IAM, a database access control system). Analyze its implementation in terms of:
Analysis of AWS IAM
Homework 3.9-5: Future of Access Control
Write a 1,500–2,000 word research paper on the future of access control. Discuss how emerging technologies such as artificial intelligence, machine learning, and zero-trust architectures are changing access control. How might access control evolve to handle the Internet of Things (IoT) and federated identity systems? What are the key challenges and opportunities?
Future of Access Control: AI, Zero Trust, and Beyond
This tutorial provided a comprehensive foundation in access control, the enforcement of security policies that determine who can access what resources and under what conditions. We began by defining the core concepts: subjects, objects, and permissions, and introduced the access control matrix as a theoretical model. We then discussed the importance of security policies and the guiding principles—least privilege, separation of duties, need-to-know, defense in depth, and fail-safe defaults—that underpin effective access control.
We provided an overview of the four major access control models: Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC). We compared their philosophies, strengths, weaknesses, and typical use cases. We also examined the mechanisms that implement these models, including Access Control Lists (ACLs), capability lists, and the PDP/PEP architectural pattern.
The administrative aspects of access control—user provisioning, privilege management, access reviews, and auditing—were discussed, along with trusted computing concepts such as the Trusted Computing Base (TCB), security kernel, and reference monitor. Two case studies illustrated how these concepts are applied in healthcare and cloud infrastructure environments.
This tutorial has laid the groundwork for deeper explorations of each access control model in the following tutorials. In Tutorial 3.10, we will focus on Discretionary Access Control (DAC), examining its implementation, advantages, and vulnerabilities in detail.
© 2026 COMP400 – Computer and Network Security • School of Computing and Information Systems, TrustOpen University • Unit 3: Authentication and Access Control