Authorization
Authorization is the process by which a system determines whether a user, program, or process has the right or permission to access a specific resource or perform a particular action, typically following authentication to verify identity.[1] In computer security, it forms a core component of access control mechanisms, ensuring that entities can only interact with systems and data in authorized ways to prevent unauthorized access, data breaches, and misuse.[2] This determination is based on policies that define permissions, often implemented through models that balance security, usability, and administrative efficiency. Authorization is distinct from authentication, which confirms an entity's identity (e.g., via passwords, biometrics, or tokens), whereas authorization specifies what that entity is allowed to do once identified.[3] For instance, a user might authenticate successfully but be denied access to sensitive files due to insufficient permissions. Common authorization models include Discretionary Access Control (DAC), where resource owners set permissions; Mandatory Access Control (MAC), enforced by a central authority based on security classifications (e.g., in multilevel security systems); and Role-Based Access Control (RBAC), which assigns permissions to roles rather than individuals, simplifying management in large organizations.[4] RBAC, standardized by NIST, has become widely adopted for its scalability, allowing permissions to be predefined and users assigned to roles dynamically.[5] These models underpin authorization in various domains, from operating systems and databases to web applications and cloud services, where frameworks like OAuth enable delegated access without sharing credentials.[6] Effective authorization reduces risks associated with the principle of least privilege, limiting access to only what is necessary for tasks, thereby enhancing overall system integrity and confidentiality.[7] As cyber threats evolve, advancements in authorization continue to incorporate attribute-based access control (ABAC) and dynamic policies to address complex, context-aware scenarios.[8]Fundamental Concepts
Definition and Scope
Authorization is the process by which a system determines whether a subject—such as a user, process, or entity—is permitted to perform a specific action on a resource, based on established policies or rules.[1] This determination grants or enforces access privileges, ensuring that only authorized interactions occur within a computing environment.[1] The scope of authorization encompasses both affirmative outcomes, where access is granted, and negative outcomes, where it is denied, to maintain system security and compliance. Central to this process are foundational elements like permissions, which specify allowable actions; roles, which group permissions for assignment to subjects; and privileges, which represent broader rights derived from those permissions.[1] Authorization forms a core component of access control, the broader framework governing resource interactions in information systems. The concept of authorization traces its origins to early computing systems in the 1970s, particularly through access control lists (ACLs) implemented in the Multics operating system, which enabled fine-grained control over file and resource sharing among multiple users.[9] Over time, it has evolved into a key pillar of modern information security, integrated into the CIA triad—confidentiality, integrity, and availability—which underpins protections against unauthorized disclosure, alteration, or disruption of data.[10] Guiding principles of authorization include the principle of least privilege, which mandates granting subjects only the minimum access necessary to accomplish their tasks, thereby minimizing potential damage from errors or compromises.[11] Complementing this is the separation of duties, which distributes conflicting responsibilities across multiple subjects to prevent any single entity from completing a high-risk action independently, reducing risks of fraud or abuse.[12]Distinction from Authentication
Authentication is the process of verifying the identity of a user, device, or system, confirming that they are who or what they claim to be, typically through methods such as passwords, biometrics, multi-factor tokens, or digital certificates.[13][14] This verification step occurs prior to authorization, establishing the subject's legitimacy before assessing their permissions.[15] The primary distinction between authentication and authorization lies in their core questions and sequencing: authentication addresses "who are you?" by validating identity, while authorization answers "what are you allowed to do?" by enforcing access rights and permissions on resources or actions.[16][17] In standard security workflows, authentication must succeed first; only then does authorization proceed to evaluate and grant or deny specific privileges based on policies, roles, or attributes.[15] These concepts form part of the Authentication, Authorization, and Accounting (AAA) framework, a foundational security triad used to manage and audit access in networks and systems.[18] Authentication handles identity verification, authorization manages policy enforcement and privilege assignment post-verification, and accounting (or auditing) tracks resource usage for compliance and monitoring.[19] This integrated approach ensures comprehensive control, with authorization specifically addressing the risks of over-permissive access after identity is confirmed.[20] Common misconceptions arise when conflating the two processes, such as assuming OAuth fully encompasses both; in reality, OAuth 2.0 is an authorization framework for delegating access to resources, often requiring separate mechanisms like OpenID Connect for authentication.[21] Similarly, single sign-on (SSO) systems primarily streamline authentication across multiple applications using shared credentials or tokens, but they do not inherently perform authorization checks, which must be implemented per resource to prevent unauthorized actions.[22][14] A typical workflow illustrates this sequence: a subject requests access to a protected resource; the system first authenticates the subject by challenging and validating their credentials—if this fails, access is immediately denied. Successful authentication triggers authorization, where the system queries policies or attributes to check permissions; if authorized, the action proceeds, but failure results in denial, ensuring no access without both validations.[15][17]Technical Frameworks
Access Control Models
Access control models provide the foundational frameworks for implementing authorization in computing systems, defining how decisions are made about granting or denying access to resources. These models evolved to address varying needs for security, flexibility, and manageability, ranging from rigid system-enforced policies to dynamic, attribute-driven evaluations. Key models include Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC), each suited to different environments such as operating systems, enterprises, and distributed networks.[23] Discretionary Access Control (DAC) allows resource owners to define and manage access permissions for other users, typically through access control lists (ACLs) that specify allowed operations like read, write, or execute. In DAC, the owner retains full discretion over privilege assignments and propagation, enabling flexible, user-centric control without central oversight. This model has been historically prominent in Unix file systems, where file permissions are set via ACLs in i-nodes, using identifiers for owner, group, and others to enforce access based on effective user and group IDs.[24] While DAC offers simplicity for small-scale systems, it is vulnerable to issues like privilege accumulation and trojan horse attacks, as users can inadvertently grant excessive rights.[23] Mandatory Access Control (MAC) enforces access decisions centrally through system-assigned security labels on subjects (users or processes) and objects (resources), preventing users from overriding policies regardless of ownership. Policies are based on labels such as clearance levels for subjects and classification levels for objects, ensuring strict enforcement for high-security contexts like confidentiality protection. The Bell-LaPadula model exemplifies MAC for confidentiality, introducing rules like the simple security property (no read up) and the *-property (no write down) to prevent unauthorized information flows in multilevel security systems.[25] SELinux implements MAC in Linux kernels via the Flask architecture, applying type enforcement and multilevel security to label processes and files, thereby containing potential breaches from compromised applications.[26] MAC provides robust security in sensitive environments but lacks flexibility, making it challenging for dynamic or user-driven scenarios.[23] Role-Based Access Control (RBAC) regulates access by assigning users to roles based on their job functions within an organization, with permissions then linked to those roles rather than individual users. Core components include users (individuals), roles (job positions), and permissions (approved operations on resources), allowing indirect access management through role assignments and hierarchies. The ANSI/INCITS 359-2004 standard formalizes RBAC, defining elements like core RBAC (basic user-role-permission relations) and extensions for separation of duties, and was revised as INCITS 359-2012 to enhance interoperability.[27] RBAC excels in enterprise scalability, efficiently handling access for organizations with over 500 users by reducing administrative overhead and minimizing errors in large-scale permission management, as evidenced by industry savings of $1.1 billion from reduced downtime.[28] However, it can suffer from role explosion in complex hierarchies, limiting adaptability to non-role-based contexts.[23] Attribute-Based Access Control (ABAC) makes authorization decisions dynamically by evaluating policies against attributes of the subject (e.g., user role or clearance), resource (e.g., classification or owner), action, and environment (e.g., time or location). Policies are expressed as rules that combine these attributes to grant or deny access, enabling context-aware and fine-grained control without predefined user mappings. The eXtensible Access Control Markup Language (XACML), an OASIS standard, facilitates ABAC policy expression through components like policy decision points (PDPs) for evaluation and policy enforcement points (PEPs) for application, supporting interoperability across systems.[23] ABAC supports external users and complex policies effectively but requires significant resources for attribute management and policy maintenance.[23] The evolution of these models traces back to the 1970s, when DAC and MAC emerged in systems like Multics and early Unix to address basic protection needs, with MAC focusing on military-grade confidentiality via models like Bell-LaPadula (1973). By the 1990s, RBAC was proposed as a scalable alternative to the limitations of DAC and MAC, formalized in 1992 by Ferraiolo and Kuhn, and standardized in 2004 to meet enterprise demands. ABAC further advanced this progression in the 2000s, incorporating dynamic attributes for modern, distributed environments.[29]| Model | Pros | Cons |
|---|---|---|
| DAC | Flexible owner control; simple for small systems | Vulnerable to privilege escalation; high administrative burden in large setups[23] |
| MAC | Strong central enforcement; high security for confidentiality | Inflexible for dynamic access; complex policy updates[23] |
| RBAC | Scalable for enterprises; simplifies role-based administration | Role explosion in hierarchies; static for contextual needs[23] |
| ABAC | Fine-grained, dynamic policies; supports external users | Complex implementation; resource-intensive maintenance[23] |
Implementation in Software Systems
In software systems, authorization is typically implemented through distinct architectural components that separate decision-making from enforcement. The Policy Decision Point (PDP) evaluates access requests against defined policies to render authorization decisions, while the Policy Enforcement Point (PEP) intercepts requests and enforces those decisions by allowing or denying access.[23] These components often integrate into middleware layers, such as API gateways, where the PEP resides at the entry point to services, querying the PDP for real-time evaluations before permitting resource access.[30] This separation enhances modularity, allowing policies to be updated centrally without altering application code. Programming approaches to authorization emphasize explicit checks embedded in code, often using simple conditional logic for permission validation. For instance, a basic permission guard in pseudocode might appear as follows:This pattern ensures fine-grained control at critical points like method invocations or API endpoints.[31] Libraries streamline these implementations; Spring Security in Java provides annotation-based authorization, such asif (user.hasPermission("read", resource)) { [return](/page/Return) resource.[data](/page/Data); } else { throw new AccessDeniedException("Insufficient permissions"); }if (user.hasPermission("read", resource)) { [return](/page/Return) resource.[data](/page/Data); } else { throw new AccessDeniedException("Insufficient permissions"); }
@PreAuthorize("hasRole('ADMIN')"), to declaratively enforce rules during request processing.[31] Similarly, Casbin offers a multi-language library supporting models like RBAC, where policies are defined in a configuration file and enforced via an enforcer.Enforce([user](/page/User), obj, act) call to check access dynamically.[32]
Authorization data is commonly stored in databases to manage permissions scalably. In relational databases, a typical schema for RBAC involves tables linking users to roles and roles to permissions, such as:
| Table | Columns | Purpose |
|---|---|---|
| users | id (PK), username | Stores user identities |
| roles | id (PK), name | Defines roles like "admin" |
| permissions | id (PK), action, resource | Specifies actions on resources |
| user_roles | user_id (FK), role_id (FK) | Assigns roles to users |
| role_permissions | role_id (FK), permission_id (FK) | Links permissions to roles |