Chapter 5: Static authorization models
The chapter introduction explains why growing systems need structured authorization models, distinguishes static from dynamic models, and notes that organizations often use several models together.
After this chapter you will be able to
- From ad hoc checks to models. Explain how ACME’s growing access needs turned scattered custom checks into inconsistent, hard-to-audit decisions, and why static authorization models provide a structured starting point.
- Static and dynamic model distinction. Distinguish static models’ predefined identity-, group-, or role-based rules from dynamic models’ use of attributes and runtime context, including the tradeoff described for each.
- Resource-attached permission lists. Explain how an ACL records permissions on a resource and how the system uses it to decide whether a principal may perform a requested action.
- Resource-centric ACL logic. Explain that an ACL attaches permissions to a resource and that access decisions depend on that resource’s list rather than external attributes or policies. Describe why this is easy to reason about locally but harder to manage at scale.
- ACL access decision check. Trace how the system checks an ACL just before access: it looks for authorization for the principal and requested action, then allows or blocks that action. Use Bob’s read-but-not-write entry or Doug’s Marketing team membership to illustrate the check.
- ACL architecture component roles. Describe how an ACL-based system can contain the reference architecture’s roles even when they are not separate components: the resource often stores the access list and makes decisions, while the PIP supplies limited identity or group information.
- Resource-local ACL strengths. Explain why attaching permissions directly to a resource makes ACL access rights easy to understand, particularly when ownership is clear and the permission list is short.
- Per-resource management at scale. Describe how growth in users, resources, and organizational requirements makes ACLs harder to maintain and oversee.
- Limits of ACL decision inputs. Distinguish the inputs ACLs use from runtime context they do not consider, and explain the resulting tradeoff.
- Suitable conditions for ACLs. Describe the conditions that make ACLs a good fit: stable, clearly defined resources; a small or bounded set of principals; clear ownership and access boundaries; and low policy complexity.
- ACL scaling and auditability. Explain why managing access per resource and per principal becomes difficult as users, resources, and access scenarios multiply, and how that difficulty affects auditing.
- Missing access rationale. Distinguish the permissions an ACL records from the business reason a person has those permissions.
- Role-based permission assignments. Explain how RBAC grants access by assigning permissions to roles and roles to principals, rather than listing permitted principals on each resource as ACLs do.
- Role-Based Access Decisions. Trace how an RBAC system decides whether to allow a user’s requested action, from identifying the user through checking permissions attached to assigned roles.
- Roles Versus Identity Groups. Distinguish identity groups from authorization roles and describe how the two can interact.
- RBAC architectural deployment. Describe how the authorization reference architecture applies to RBAC in smaller and larger systems.
- Role-Based Management Benefits. Explain how assigning access through organizational roles made onboarding, communication, and audits easier at ACME than scattered ACLs and hardcoded checks.
- Context-Dependent Access Limits. Explain why RBAC works best with stable, clear responsibilities but becomes less clear when access depends on a particular issue, on-call status, or project relationship.
- Good fits for RBAC. Explain why RBAC suits access needs tied to stable job or operational responsibilities, and give examples of settings where it works well. Describe why it can be a practical starting point for teams with limited authorization needs.
- Context encoded as roles. Describe how adding a new role for each access condition can cause roles to proliferate, and explain why some conditions are better expressed as attributes, relationships, or runtime policy inputs.
- Role explosion. Explain how edge cases and special conditions can cause teams to create many narrowly scoped roles instead of maintaining a stable set of job-aligned roles.
- Contextual access limits. Explain why RBAC alone cannot express access conditions based on time of day, device security posture, or network zone.
- Resource relationship limits. Explain why roles can be too broad or unclear in multi-tenant or collaborative settings where access depends on a person's relationship to a resource.
- Limits of static models. Explain why ACLs and RBAC become harder to manage as interconnected systems require more contextual access exceptions.
- Changing access decision factors. Describe why an access decision may need to consider factors that change between requests, rather than only a job title or list membership.
What it builds on
- From architecture to models (chapter 4) · The transition from authorization architecture to models.
- Architecture patterns in practice (chapter 4) · The existence of different authorization architecture patterns.
- The PARC model (chapter 4) · The authorization request’s principal, action, and resource.
- Authorization reference architecture (chapter 4) · Introduces the authorization reference architecture.
- Identity and digital relationships (chapter 2) · The idea that identity systems represent people and their organizational relationships.
Section by section
Introduction
The chapter introduction explains why growing systems need structured authorization models, distinguishes static from dynamic models, and notes that organizations often use several models together.
- From ad hoc checks to models: Explain how ACME’s growing access needs turned scattered custom checks into inconsistent, hard-to-audit decisions, and why static authorization models provide a structured starting point.
Why it matters: This explains the problem that structured authorization models are meant to address. - Static and dynamic model distinction: Distinguish static models’ predefined identity-, group-, or role-based rules from dynamic models’ use of attributes and runtime context, including the tradeoff described for each.
Why it matters: The distinction helps explain both the appeal and the limits of static models. - Multiple models in practice: Describe why understanding authorization models is not simply a matter of choosing one model for an entire organization.
Why it matters: Real systems require working across existing approaches, not assuming one model governs every decision.
Key terms: static authorization models, access decisions, custom if-then conditionals, static models, dynamic models, predefined rules, real-time context, roles, attributes, relationships
5.1 Access Control Lists
This section explains how resource-attached access control lists determine access, illustrates the model with Unix permissions, and identifies where ACLs fit best.
- Resource-attached permission lists: Explain how an ACL records permissions on a resource and how the system uses it to decide whether a principal may perform a requested action.
Why it matters: This is the basic decision rule behind every ACL example in the section. - Unix permissions as simplified ACLs: Describe how Unix file permissions express the ACL idea and how their fixed categories differ from ACLs with named principals.
Why it matters: Familiar file permissions make the ACL model concrete while showing a limit of its simplest form. - Suitable settings for ACLs: Explain when the section says ACLs are a good fit and why changing access needs can make them less suitable.
Why it matters: It helps distinguish a useful application of ACLs from a situation that calls for closer scrutiny.
Key terms: ACL, principal, permissions, resource-centric, Unix permissions, owner, group, others, read, write
5.1.1 How ACLs work
Explains how resource-attached access control lists decide whether a principal may perform an action, including common variations and their management tradeoff.
- Resource-centric ACL logic: Explain that an ACL attaches permissions to a resource and that access decisions depend on that resource’s list rather than external attributes or policies. Describe why this is easy to reason about locally but harder to manage at scale.
Why it matters: The resource-centric design explains both the simplicity and the scaling difficulty of ACLs. - ACL access decision check: Trace how the system checks an ACL just before access: it looks for authorization for the principal and requested action, then allows or blocks that action. Use Bob’s read-but-not-write entry or Doug’s Marketing team membership to illustrate the check.
Why it matters: An ACL entry only helps if it authorizes the action being attempted on that resource. - Common ACL implementation variations: Describe how ACL implementations can differ in their handling of Allow and Deny entries, group or wildcard entries, and inherited permissions on child resources.
Why it matters: These variations explain how real ACL systems can grant broader access or manage nested resources without listing every permission individually.
Key terms: ACL, resource-centric logic, permissions, authorization time, principal, action, Allow, Deny, groups, wildcards
5.1.2 Mapping ACLs onto the authorization reference architecture
This subsection maps ACL-based systems onto the authorization reference architecture and explains the tradeoff created by their tightly coupled design.
- ACL architecture component roles: Describe how an ACL-based system can contain the reference architecture’s roles even when they are not separate components: the resource often stores the access list and makes decisions, while the PIP supplies limited identity or group information.
Why it matters: Recognizing the roles inside an embedded ACL system makes it possible to compare ACLs with other authorization models. - Tight coupling tradeoff: Explain why embedding ACL functions in a resource or application can be simple and efficient but harder to scale across distributed systems or centralize for governance.
Why it matters: The tradeoff helps explain both the appeal and the limits of embedded ACL systems.
Key terms: ACLs, PEP, PDP, PAP, PIP, authorization reference architecture, tight coupling, distributed systems, governance
5.1.3 Strengths and limitations of ACLs
This section explains why ACLs are clear and practical for bounded resources but become difficult to manage at scale and cannot adapt to runtime context.
- Resource-local ACL strengths: Explain why attaching permissions directly to a resource makes ACL access rights easy to understand, particularly when ownership is clear and the permission list is short.
Why it matters: This explains why ACLs remain useful rather than being replaced in every setting. - Per-resource management at scale: Describe how growth in users, resources, and organizational requirements makes ACLs harder to maintain and oversee.
Why it matters: A locally simple control can become brittle when an organization needs consistent access management across systems. - Limits of ACL decision inputs: Distinguish the inputs ACLs use from runtime context they do not consider, and explain the resulting tradeoff.
Why it matters: This identifies the kind of access decision for which a resource permission list is not enough.
Key terms: Access Control Lists, resource, permissions, ownership model, ACLs, resource by resource, exceptions, consistency, visibility, change management
5.1.4 Where ACLs still make sense
This section explains when ACLs remain a practical authorization choice and illustrates where they are still used.
- Suitable conditions for ACLs: Describe the conditions that make ACLs a good fit: stable, clearly defined resources; a small or bounded set of principals; clear ownership and access boundaries; and low policy complexity.
Why it matters: These conditions help you recognize when a straightforward ACL is enough. - Practical value and uses: Explain why ACLs remain useful in small applications and give examples of systems that still use them, such as operating systems controlling file access or databases granting privileges on tables.
Why it matters: A simpler access model can be the better choice when a more elaborate one brings little benefit.
Key terms: ACLs, resources, principals, ownership and access boundaries, policy complexity, role or policy engine, transparency, direct control
5.1.5 When ACLs fall short
This section explains why ACLs become difficult to manage and audit at scale, why they cannot express the reason for access, and how roles offer a more manageable approach.
- ACL scaling and auditability: Explain why managing access per resource and per principal becomes difficult as users, resources, and access scenarios multiply, and how that difficulty affects auditing.
Why it matters: An access model must remain manageable when both the system and its audit obligations grow. - Missing access rationale: Distinguish the permissions an ACL records from the business reason a person has those permissions.
Why it matters: A permission entry alone cannot explain whether the reason for granting access still applies. - Roles as permission bundles: Describe how RBAC introduces roles tied to job functions or responsibilities as a more consistent way to assign and manage permissions.
Why it matters: Roles show the direction of the chapter’s response to the management difficulties of individual ACL entries.
Key terms: ACLs, per-resource, per-principal, auditing access decisions, business rationale, permissions, RBAC, roles, bundles of permissions, job functions
5.2 Role-Based Access Control
This section introduces RBAC as a way to manage access through job-based roles rather than direct user permissions, and explains its practical benefits and role hierarchies.
- Role-based permission assignments: Explain how RBAC grants access by assigning permissions to roles and roles to principals, rather than listing permitted principals on each resource as ACLs do.
Why it matters: This indirection is the defining shift from ACLs to RBAC. - Access management through roles: Describe how role assignments simplify access changes as people join or change jobs, while improving consistency and visibility without eliminating all complexity.
Why it matters: Roles make routine staffing changes easier to administer and access easier to review. - Inherited role permissions: Explain how a role hierarchy lets one role inherit another role’s permissions and add privileges suited to greater responsibility.
Why it matters: Inheritance expresses seniority without separately assigning every underlying permission or role.
Key terms: RBAC, roles, permissions, principals, ACLs, role changes, identity life cycle events, centralized picture, role hierarchies, role inheritance
5.2.1 How RBAC works
This section explains how RBAC decides access through roles and permissions, how hierarchies and separation-of-duty constraints affect it, and how roles differ from groups.
- Role-Based Access Decisions: Trace how an RBAC system decides whether to allow a user’s requested action, from identifying the user through checking permissions attached to assigned roles.
Why it matters: This is the basic decision path behind every RBAC example in the section. - Inherited Role Permissions: Explain how a role hierarchy changes the permissions considered when RBAC evaluates a request.
Why it matters: A permission can count even when it comes through an inherited role rather than an immediately assigned one. - Separation of Duty Constraints: Describe what separation of duty constraints prevent and why an RBAC system might enforce them.
Why it matters: RBAC can govern which combinations of authority a person may hold, not just which actions a role permits. - Roles Versus Identity Groups: Distinguish identity groups from authorization roles and describe how the two can interact.
Why it matters: Distinguishing identity organization from permission-bearing roles makes it easier to explain where access authority comes from. - RBAC Consistency And Limits: Explain why role-based permissions can make decisions predictable and identify the dynamic conditions this section says RBAC does not support.
Why it matters: The benefit and boundary help explain when role-based decisions are useful and when roles alone are insufficient.
Key terms: RBAC, principal, roles, permissions, role hierarchies, inherits, inherited roles, separation of duty, SoD, conflicting roles
5.2.2 Mapping RBAC onto the authorization reference architecture
This section shows that RBAC fits the authorization reference architecture whether its responsibilities live inside an application or in shared services.
- RBAC architectural deployment: Describe how the authorization reference architecture applies to RBAC in smaller and larger systems.
Why it matters: It helps you recognize the same RBAC model in applications with very different architectures. - RBAC architectural versatility: Explain why the section connects RBAC’s ability to separate architectural concerns with its endurance.
Why it matters: It explains why an RBAC implementation can change as a system grows without abandoning RBAC.
Key terms: RBAC, authorization reference architecture, PEP, PDP, PAP, PIP, separating concerns, externalized authorization services
5.2.3 Strengths and limitations of RBAC
This section explains why RBAC is manageable and auditable when responsibilities are stable, and why it loses clarity when access depends on changing context or individual relationships.
- Role-Based Management Benefits: Explain how assigning access through organizational roles made onboarding, communication, and audits easier at ACME than scattered ACLs and hardcoded checks.
Why it matters: This explains why RBAC remains useful despite its limitations. - Context-Dependent Access Limits: Explain why RBAC works best with stable, clear responsibilities but becomes less clear when access depends on a particular issue, on-call status, or project relationship.
Why it matters: This tradeoff helps explain when job-based roles stop being a clean description of who should have access.
Key terms: RBAC, organizational roles, role assignments, auditability, dynamic, contextual, roles and exceptions
5.2.4 Where RBAC still makes sense
This section explains when RBAC is a practical choice and how encoding changing access conditions as roles can make it unwieldy.
- Good fits for RBAC: Explain why RBAC suits access needs tied to stable job or operational responsibilities, and give examples of settings where it works well. Describe why it can be a practical starting point for teams with limited authorization needs.
Why it matters: This helps you recognize when a straightforward role model is sufficient. - Context encoded as roles: Describe how adding a new role for each access condition can cause roles to proliferate, and explain why some conditions are better expressed as attributes, relationships, or runtime policy inputs.
Why it matters: Recognizing role proliferation helps distinguish a useful role model from one being stretched to represent context.
Key terms: RBAC, roles, job functions, context, attributes, relationships, runtime policy inputs
5.2.5 Where RBAC falls short
This section explains where RBAC’s structured roles fall short as access needs become more varied, contextual, and resource-specific.
- Role explosion: Explain how edge cases and special conditions can cause teams to create many narrowly scoped roles instead of maintaining a stable set of job-aligned roles.
Why it matters: A growing collection of role variations is a sign that RBAC may no longer fit the access requirements well. - Contextual access limits: Explain why RBAC alone cannot express access conditions based on time of day, device security posture, or network zone.
Why it matters: A role by itself cannot answer an access question that depends on the circumstances of the request. - Resource relationship limits: Explain why roles can be too broad or unclear in multi-tenant or collaborative settings where access depends on a person's relationship to a resource.
Why it matters: A person's general role may not show which specific resources they own, share, or work on with a team.
Key terms: RBAC, role explosion, job-aligned roles, contextual access, device security posture, network zone, dynamic evaluation, multi-tenant, collaborative environments, relationship to a resource
5.3 Beyond static authorization
This section explains why ACLs and RBAC become harder to use as access decisions depend on changing context rather than static assignments.
- Limits of static models: Explain why ACLs and RBAC become harder to manage as interconnected systems require more contextual access exceptions.
Why it matters: It explains why a clear static access model can become difficult to reason about as requirements grow. - Changing access decision factors: Describe why an access decision may need to consider factors that change between requests, rather than only a job title or list membership.
Why it matters: The same person may need a different access decision when the circumstances of a request change.
Key terms: ACLs, RBAC, static models, exceptions, context, runtime conditions, time, device state, resource relationship, external obligations
5.4 Summary
Where this is used later
- (chapter intro) (chapter 6) · Frames the introduction to dynamic authorization models.
- A hybrid approach: Policy-based access control (chapter 6) · Provides context for discussing a hybrid approach.
- Relationship-based access control (chapter 6) · ACLs as a static access control model.
- Beyond one-size-fits-all (chapter 6) · The ACL model used for simple resource access.
- Attribute-based access control (chapter 6) · Provides the role-based model that this section contrasts with ABAC.
- When ABAC falls short (chapter 6) · The limitations of role-based access control, including proliferating roles.
- How ABAC works (chapter 6) · Motivates an access-control model that can account for attributes and context.
- How ReBAC works (chapter 6) · Motivates considering relationships between people and resources in access decisions.
Concepts explained in this chapter
- role-based access controlRole-based access control is an authorization model that assigns permissions to roles and grants principals those roles rather than assigning permissions directly to each principal.
- access control listAn access control list is a list of permissions associated with a resource that specifies which entities or groups may access it.
- authorizationAuthorization is the process of determining and enforcing what an authenticated identity is permitted to access or do.
- roleA role is an authorization abstraction that groups permissions or access responsibilities for assignment to principals.
- groupA group is a named collection of principals or resources to which shared access rules can be applied.
- authorization modelAn authorization model is a conceptual scheme for representing authority and determining how permissions are assigned or evaluated.
- actionAn action is an operation that a principal attempts to perform on a resource.
- principalA principal is an entity, such as a person, machine, or process, that can initiate an action in an authorization system.
- role hierarchyA role hierarchy is an authorization structure in which roles can inherit permissions from other roles to represent levels of responsibility.
- Unix file permissionsA Unix operating-system mechanism that assigns read, write, and execute rights to files and directories for owners, groups, and other users.
- resource-based access controlA resource-based policy is an authorization policy attached to a resource that specifies which principals may access it and under what conditions.
- static authorizationA static authorization system evaluates access using fixed authorization data rather than changing request context.
- role explosionRole explosion is the proliferation of narrowly scoped authorization roles created to accommodate exceptions, contextual conditions, or edge cases.
- role assignmentA role assignment is a configuration that associates a principal with an authorization role.
- policy-based access controlPolicy-based authorization determines access from explicitly defined rules or policies evaluated against identities, resources, actions, and conditions.
- attribute-based access controlAttribute-based access control (ABAC) is an authorization approach that makes decisions by evaluating attributes of subjects, resources, actions, and contextual conditions against rules.
- authorization decisionAn authorization decision is the determination of whether a principal is allowed to perform an action on a resource.
- relationship-based access controlA relationship permission is an access rule or authorization pattern in which permission depends on an authorization-relevant relationship between entities.
- policy administration pointA policy administration point is an authorization architecture component through which policies or policy-relevant relationships are created and modified.
- policy enforcement pointAn enforcement point is a system component or boundary at which an authorization decision is applied to allow or prevent an operation.
- policy information pointA policy information point is an authorization component that supplies identity, attribute, relationship, or contextual information for policy evaluation.
- separation of dutiesSeparation of duties is a control principle that assigns a sensitive process to multiple people so that no single person performs all conflicting responsibilities.
- dynamic authorization modelA dynamic authorization model evaluates access decisions from changing policies, identities, resources, or contextual conditions rather than fixed permissions alone.
- conditionA condition is a contextual requirement that determines whether an authorization request is permitted or denied.
- contextContext is the current information and attributes surrounding an access request that can affect an authorization decision.
- device posture signalDevice posture is a current, context-dependent assessment of a device's trustworthiness based on its management, security controls, health, environment, and recency of attestation.
- edgeA relationship edge is a graph connection that records an association between entities or between an entity and a resource.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.