Chapter 6: Dynamic authorization models

Introduction

ACME’s experience shows why static roles remain useful but need to be complemented by relationship- and attribute-based decisions, brought together through policies.

• RBAC benefits and limits: Explain why RBAC initially helped ACME and why it became insufficient as access needs grew more varied.
  Why it matters: The reason for adding dynamic authorization is easier to see when roles’ continuing value and their limits are both clear.
• Relationships versus attributes: Distinguish ACME’s examples of relationship-based and attribute-based access decisions.
  Why it matters: These examples show two ways to make access reflect the particular work and resource involved.
• Policies as unifying layer: Describe how policies brought ACME’s different approaches together without requiring every permission to be hardcoded or expressed as a static role.
  Why it matters: Policies give ACME a common way to state access rules while accommodating different kinds of decision data.

Key terms: Role-Based Access Control (RBAC), static authorization, dynamic authorization models, Relationship-Based Access Control (ReBAC), Attribute-Based Access Control (ABAC), viewer, editor, owner, policy-based access control (PBAC), policies

6.1 Relationship-based access control

This section introduces ReBAC as relationship-based authorization and shows how a graph of people, resources, and their connections can support access decisions in collaborative systems.

• Relationship-Based Access Decisions: Explain how ReBAC bases access on a principal’s relationship to a resource rather than only on a static access list or assigned role.
  Why it matters: It identifies what ReBAC uses to decide access.
• Relationship Graph Access Paths: Describe how ReBAC represents entities and relationships in a graph and checks for a path that satisfies a policy condition.
  Why it matters: The graph explains how both direct and indirect relationships can justify access.
• Collaborative Access Fit: Explain why relationship-based authorization suits collaborative, multi-tenant systems, using an example from the section.
  Why it matters: It connects the model to the changing relationships that govern shared customer work.

Key terms: ReBAC, principal, resource, relationship, graph, nodes, edges, path, policy condition, collaborative

6.1.1 How ReBAC works

This section explains how ReBAC evaluates access using stable rules and a changing graph of relationships between people, teams, and resources.

• Relationship Based Access Decisions: Explain that ReBAC decides access from the relationship between a principal and a resource, using static rules and current relationship data rather than relying only on roles or attributes. Describe how ACME’s authorization service evaluates a document request.
  Why it matters: This is the basic decision pattern behind the section’s examples.
• Transitive Relationship Access: Trace why Carol can access Alice’s deployment plan through the manager → owner → resource chain, and explain what happens if Alice ceases to own the plan.
  Why it matters: The example shows how a relationship change can automatically change who has access.
• Changing Relationships Within Guardrails: Explain why ACME can change access by updating ownership, team rights, or collaborator relationships without rewriting rules or deploying code, while keeping those changes within the rules’ guardrails.
  Why it matters: Separating stable rules from changing relationships lets collaborators manage access without constant policy churn.

Key terms: ReBAC, principal, resource, static rules, authorization service, relationship graph, transitive rule, manager → owner → resource, policy data, guardrails

6.1.2 Mapping ReBAC onto the authorization reference architecture

This section maps ReBAC to the authorization reference architecture by showing how user interfaces can administer relationship data and how PIPs supply that data for access decisions.

• User interface as PAP: Explain how a sharing or membership interface can act as a PAP in ReBAC by changing the relationship graph and, with it, future access decisions.
  Why it matters: It explains how ordinary sharing actions can administer access in a ReBAC system.
• PIP data for decisions: Distinguish the PIP’s role from the PAP’s: describe how it supplies the decision engine with the relationship graph and potentially other information needed to evaluate access.
  Why it matters: It separates changing relationship data from supplying that data when an access decision is made.

Key terms: ReBAC, PAP, relationship graph, policy administration, PIP, decision engine, identity provider

6.1.3 Strengths and limitations of ReBAC

This section explains why ReBAC suits changing, collaborative relationships, how it supports delegated permission management, and where its limitations call for other authorization models.

• Relationship graph access fit: Explain how ReBAC uses relationships to determine access and why this suits collaborative systems with changing social, organizational, or ownership structures.
  Why it matters: It explains why relationships, rather than fixed roles, can be a useful foundation for collaborative access.
• Delegated permission management: Describe how ReBAC lets people close to the work grant and revoke permissions through relationship changes, and why that delegation requires trust.
  Why it matters: Delegation makes permissions easier to manage as teams change, but it also puts access decisions in users’ hands.
• Graph limits and complementary models: Explain why complex relationship graphs can make access hard to understand and why ReBAC needs other models for context-aware conditions.
  Why it matters: Recognizing these limits helps prevent confusing or unintended access and keeps ReBAC from being used for conditions it cannot express well.

Key terms: ReBAC, relationship graph, authorized path, principal, resource, data as policy, delegation, policy authoring, permissions, relationship paths

6.1.4 Where ReBAC makes sense

This section explains why ReBAC suits collaborative systems and how relationship-based permissions can adapt as those systems change.

• Relationship-centered access fit: Explain when ReBAC is a good fit and illustrate it with ACME’s Customer Collaboration platform. Describe how ownership, collaboration, and management relationships determine access more naturally than static roles or fragile attribute rules.
  Why it matters: It helps identify when relationships describe access more clearly than fixed roles.
• Adaptive permissions and governance: Explain how ReBAC permissions respond to changing relationships as a system grows, and distinguish business teams’ day-to-day access actions from governance teams’ continuing oversight.
  Why it matters: It shows how access can keep pace with collaboration without making governance teams handle every change.

Key terms: ReBAC, shared graph, account ownership, management chains, permissions, graph, governance teams

6.1.5 When ReBAC falls short

This section explains when relationship-based access control (ReBAC) is a poor fit and why its relationship graph needs operational safeguards.

• Relationships versus runtime conditions: Explain why ReBAC alone is a poor fit when access depends on transient conditions, and distinguish those conditions from the durable connections a relationship graph should represent.
  Why it matters: Choosing the right model keeps temporary access conditions from becoming confusing, misleading relationships.
• Relationship graph operational risks: Describe why changing entities and relationships can make ReBAC difficult to manage, govern, and audit, and state the safeguards the section recommends.
  Why it matters: A graph that is easy to change still needs controls against unexpected access changes.

Key terms: ReBAC, relationship graph, runtime context, attributes, ABAC, life cycle management, relationship pathways, governance, auditing, guardrails

6.2 Attribute-based access control

This section introduces attribute-based access control as a way to make access decisions from attributes and current conditions rather than roles or relationships alone.

• Attribute-based access decisions: Explain how ABAC evaluates policies using attributes of the principal, resource, environment, or request at the time of an access decision, and why this supports context-aware control beyond roles or relationships alone.
  Why it matters: It explains how access can change with the resource, request, or circumstances, even for the same person.
• Conditions in ACME access examples: Describe how an ACME example combines attributes to limit access, such as clearance and time for financial data, or clearance, device, and on-call status for deployments.
  Why it matters: The examples make clear why belonging to the right group may not, by itself, be enough for a sensitive action.

Key terms: ABAC, attributes, principal, resource, environment, request, clearance, department, company-managed device, on call

6.2.1 How ABAC works

This section explains how ABAC evaluates current attributes against stable, sometimes layered policies to make context-sensitive access decisions.

• Attribute-Based Access Decisions: Trace how an ABAC policy uses principal, resource, and environmental attributes to decide whether a request is permitted, using Alice and Bob’s document requests as examples.
  Why it matters: This example shows how an access decision follows from specific conditions rather than a user’s identity alone.
• Stable Policies Dynamic Inputs: Explain why ABAC decisions can change between requests even when the policy does not.
  Why it matters: It distinguishes a changing access decision from a change to the rule itself.
• Layered Policy Evaluation: Describe how a real ABAC decision can draw on multiple attribute sources and policies, including both baseline and more specific requirements.
  Why it matters: A request may have to satisfy organization-wide safeguards as well as conditions specific to an application or action.
• Deployment Access Conditions: Apply ACME’s stated deployment rules to explain how device status, clearance, time, and on-call status affect a deployment request.
  Why it matters: The deployment example makes the effect of several simultaneous ABAC conditions concrete.

Key terms: ABAC, principal, resource, environment, policy engine, attributes, policies, policy language, policy stores, layered policies

6.2.2 Mapping ABAC onto the authorization reference architecture

This section maps ABAC onto the authorization reference architecture and explains why fast policy evaluation and trustworthy attributes matter in production.

• ABAC request and decision flow: Trace how a PEP intercepts an action-specific request and asks the PDP for an allow-or-deny decision. Explain that the PDP evaluates relevant policies against current attributes, so decisions can change even when policies do not.
  Why it matters: It connects ABAC’s changing inputs to the components that make each access decision.
• Policy evaluation at scale: Explain why finding and evaluating the right policies quickly becomes difficult as their number grows, and name the approaches this section gives for keeping decisions fast.
  Why it matters: A correct access decision is useful only if the system can make it promptly in production.
• Attribute trust and governance: Explain why a well-written ABAC policy can still produce a wrong decision when its attributes are stale, inconsistent, or poorly governed. Describe the section’s conclusion that production ABAC needs policy management through the PAP and attribute governance through the PIP.
  Why it matters: Accurate policy logic cannot compensate for unreliable facts used to make a decision.

Key terms: ABAC, PEP, PDP, attributes, allow or deny, policy metadata, indexing, caching, distributed PDPs, PAP

6.2.3 Strengths and limitations of ABAC

This section explains why ABAC supports precise, context-aware access decisions and what operational work is needed to make those decisions reliable and understandable.

• Context-sensitive access decisions: Explain how ABAC uses attributes about the principal, resource, action, and environment to make fine-grained decisions, and contrast this with granting everyone in an RBAC role the same access. Describe how reusable policies adapt when attributes change, using the financial-report example.
  Why it matters: This is why ABAC can express access requirements that vary by situation without creating a role for every scenario.
• Attribute quality and policy operations: Explain the operational limitations that accompany ABAC’s flexibility: obtaining accurate, fresh attributes from multiple sources, managing code-like policies, and explaining decisions through logging and analysis tools. State what organizations must invest in to realize ABAC’s benefits.
  Why it matters: Flexible policies are useful only if their inputs can be trusted and their decisions can be managed and explained.

Key terms: ABAC, attributes, principal, resource, action, environment, attribute quality, freshness, governance, logging

6.2.4 Where ABAC makes sense

This section explains when ABAC is a good fit and shows how runtime attributes and layered policies support context-aware access across an enterprise.

• Dynamic access conditions: Explain why ABAC suits access decisions that depend on changing, fine-grained conditions rather than only static assignments or predefined relationships.
  Why it matters: It helps you recognize when changing context needs to shape an access decision.
• Layered departmental policies: Describe how ACME combines a company-wide access requirement with department-specific ABAC policies while letting teams retain control of their own rules.
  Why it matters: The ACME example shows how local flexibility can coexist with consistent organization-wide safeguards.
• Independent policy and attribute sources: Explain how separating ABAC policy from identity and data systems helps rules scale across teams and tools.
  Why it matters: This explains why context-aware rules need not be rebuilt separately inside every application.

Key terms: ABAC, dynamic factors, fine-grained conditions, runtime signals, company-wide policy, baseline requirement, shared organizational constraints, composable, policy, attributes

6.2.5 When ABAC falls short

This section explains where ABAC’s flexibility falls short: policy and attribute sprawl, difficulty expressing changing relationships, and centrally managed policy bottlenecks, while noting that governance can reduce some problems.

• Policy and attribute sprawl: Explain how many similar ABAC policies and inconsistently named attributes make it difficult to identify applicable rules and understand access decisions.
  Why it matters: Flexibility is less useful when teams cannot tell which rule applies or why access was granted.
• Dynamic relationship access limits: Describe why ACME found attribute-driven policies awkward for access based on changing relationships, such as invitations, temporary document access, and account ownership.
  Why it matters: The kind of access being modeled matters as much as how precisely a policy can evaluate conditions.
• Central policy management bottleneck: Explain how centrally written ABAC policies can delay new access rules and limit delegation and self-service, despite attributes coming from distributed sources.
  Why it matters: Distributed attribute data does not by itself give teams authority to change access rules when they need to.
• Governance as complexity mitigation: Describe how consistent naming, clear policies, version control, and testing or simulation can reduce ABAC complexity without making ABAC a universal solution.
  Why it matters: Better governance can make ABAC more sustainable without assuming it fits every access pattern.

Key terms: ABAC, role explosion, policies, attributes, taxonomy, ReBAC, dynamic, graph-based relationships, Customer Collaboration platform, centrally managed policies, delegation

6.3 A hybrid approach: Policy-based access control

This section explains why varied authorization needs call for PBAC and how PBAC makes externalized policies the decision-making unit across roles, attributes, and relationships.

• Need for a hybrid model: Explain why ACME could not rely on a single role-, relationship-, or attribute-based model for all its access needs.
  Why it matters: The variety of access needs explains why ACME needs a unified approach.
• Externalized PBAC policy decisions: Describe how PBAC uses externalized policies to make access decisions using current roles, attributes, conditions, or relationships as inputs.
  Why it matters: This is the section’s central distinction between PBAC and keeping separate, hardcoded access models.

Key terms: roles, relationships, attributes, PBAC, externalizes access logic, policies, runtime

6.3.1 Policy as Data

The section explains how Policy as Data lets stable relationship-based rules produce changing access decisions as the relationship graph changes.

• Dynamic access from relationship data: Explain how Policy as Data uses reusable rules over relationship data so access outcomes change when the graph changes, without changing the policy logic.
  Why it matters: It explains how access can adapt to changing relationships without rewriting rules.

Key terms: Policy as Data, PBAC, relationship graph, structured input data

6.3.2 Policy as Code

The section explains Policy as Code through ABAC’s executable rules, contrasts it with relationship-based access, and places both within PBAC.

• Attribute-Based Policy Evaluation: Explain that ABAC policies are executable rules evaluated by a policy engine using current contextual attributes, rather than granting access through relationship data as ReBAC does.
  Why it matters: This distinction helps you recognize whether access is determined by evaluating a rule or by looking up a relationship.
• Code Policy Management Tradeoffs: Describe how code-based policies can be authored in a policy language, stored, combined or layered, and managed with version control, while being more complex to create and maintain than relationship data.
  Why it matters: The benefits of precise, adaptable rules come with a practical maintenance cost.
• Shared PBAC Architecture: State that PBAC provides a shared authorization architecture across systems whether policies use relationship graphs or executable rules.
  Why it matters: The two policy representations need not imply entirely separate authorization architectures.

Key terms: ABAC, ReBAC, Policies as Code, policy engine, contextual attributes, relationship data, policy stores, version control, Cedar, Rego

6.3.3 Beyond one-size-fits-all

This section explains how policy-based authorization combines different access-control models rather than replacing them with one model for every situation.

• PBAC as a unifying framework: Explain how PBAC brings roles, attributes, and relationships into a common approach by externalizing decision logic and evaluating it at runtime.
  Why it matters: A common framework lets teams make consistent access decisions without forcing every system into the same model.
• Choosing models by access need: Describe why ACME retained different authorization models for different needs as it grew, rather than replacing each earlier model outright.
  Why it matters: Matching models to access needs explains why an organization may keep several models as its systems grow.

Key terms: PBAC, externalize decision logic, runtime, roles, attributes, relationships, ACLs, RBAC, ReBAC, ABAC

6.4 Summary