The chapter introduces static authorization as the set of access-control approaches that rely on predefined identities, groups, roles, and resource-attached rules rather than changing runtime context. Using the example of a growing company, it shows how informal, hardcoded checks can quickly become unmanageable as teams, systems, and compliance needs expand. Static models provide an important starting point because they are understandable, efficient, and easy to reason about locally, even though they do not adapt well to changing conditions.
Access Control Lists are presented as the most direct static model: permissions are attached to a resource and evaluated when someone tries to use it. An ACL acts like a resource-specific guest list, allowing or denying actions based on named users or groups, with variations such as deny rules, inheritance, and limited role structures in systems like Unix permissions. ACLs work best when resources are stable, ownership is clear, and the number of principals is limited, but they become difficult to manage when access must be coordinated across many resources and users.
Role-Based Access Control addresses some of those problems by assigning permissions to roles and then assigning users to those roles. This adds abstraction, makes onboarding and job changes easier, improves auditability, and supports role hierarchies and separation-of-duty constraints. However, RBAC still struggles with exceptions, role explosion, and contextual needs like time, device posture, or resource relationships, which is why the chapter positions ACLs and RBAC as useful but limited foundations that often need to be combined with more dynamic models in modern systems.
An ACL attached to a shared resource. The ACL specifies which principals—such as Alice, Bob, and the Marketing group—are authorized to access the “Marketing Campaign Plans” folder and outlines the actions they are allowed to perform.
Users are assigned to roles like engineer, senior-engineer, or support-lead, which define the permissions they receive. Some roles inherit from others, allowing access to be layered and managed through the organizational structure.
Summary
Static authorization models evaluate access based on predefined lists or assignments and are efficient to evaluate at runtime.
Access Control Lists (ACLs) attach permissions directly to resources, making them simple and transparent but difficult to manage at scale.
Role-Based Access Control (RBAC) introduces roles as an intermediary, aligning access with organizational structure and improving manageability.
Both ACLs and RBAC map onto the standard authorization reference architecture, though often with tightly coupled or application-embedded components.
RBAC supports additional governance features, such as separation of duty constraints and role hierarchies, but lacks support for dynamic context.
Static models remain widely used and appropriate in systems with stable responsibilities and clearly bounded access needs.
As systems grow more dynamic and complex, static models struggle to adapt, creating a need for more expressive, context-aware approaches.
FAQ
What is a static authorization model?Static authorization models rely on predefined rules tied to identities, groups, or roles. They are generally easy to understand and efficient to evaluate, but they do not adapt well to changing runtime conditions or context.What is the main difference between ACLs and RBAC?ACLs attach permissions directly to resources and list specific users or groups allowed to act on them. RBAC assigns permissions to roles, then assigns users to those roles, so access is managed indirectly through job functions or responsibilities.How does an Access Control List (ACL) work?An ACL is attached to a resource and lists which principals can perform which actions. When a request is made, the system checks the resource’s ACL at authorization time to decide whether to allow or deny the action.Why are ACLs described as resource-centric?ACLs store access control logic with the resource itself rather than in a centralized policy or identity system. The access decision depends on what is listed for that resource, not on external attributes or broader organizational policy.What are the strengths of ACLs?ACLs are simple, direct, and easy to understand. They offer fine-grained control over individual resources, are fast to evaluate, and work well in small or clearly bounded environments with stable ownership.What are the main limitations of ACLs?ACLs become difficult to manage at scale because permissions must be maintained resource by resource. They also lack a global view of access, are hard to keep consistent across many resources, and do not support contextual or conditional access.What is Role-Based Access Control (RBAC)?RBAC is a model where permissions are assigned to roles instead of directly to users. Users gain access by being assigned one or more roles that reflect job functions or organizational responsibilities.How does RBAC improve over direct user-to-resource permissions?RBAC centralizes permission management and makes access easier to change when people join, leave, or change jobs. Instead of updating many resource-specific rules, administrators update role assignments and role permissions.What are the strengths and limitations of RBAC?RBAC provides clarity, consistency, auditability, and scalability for structured organizations. Its limitations include role explosion, difficulty handling exceptions, and weak support for dynamic context such as time, device state, or location.When do ACLs and RBAC still make sense today?ACLs still make sense when resources are stable, the number of principals is small, and access rules are simple. RBAC still works well in enterprise, internal, regulated, or infrastructure environments where roles are well defined and access aligns with job responsibilities.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
Authorization in Action ebook for free
