liveBook · Manning

Dynamic authorization model

As explained in Authorization in Action

A dynamic authorization model evaluates access decisions from changing policies, identities, resources, or contextual conditions rather than fixed permissions alone.

A dynamic authorization model makes access decisions from changing policies, identities, resources, relationships, and context—not from fixed permissions alone. It helps organizations handle conditions such as a user’s region, a record’s sensitivity, a document relationship, or the time of day. section 6.0

Dynamic authorization addresses the point where static permissions and accumulating exceptions become difficult to review and keep consistent across systems. Declarative policies provide the layer connecting identity and resource data with business and security conditions. section 6.0 section 5.0

Common dynamic approaches include:

  • Relationship-Based Access Control (ReBAC) grants access according to a user’s relationship to a resource, such as viewer, editor, or owner. section 6.0
  • Attribute-Based Access Control (ABAC) evaluates attributes such as region, clearance, time of day, and record sensitivity. section 6.0
  • Role-Based Access Control (RBAC) remains useful for broad responsibilities, onboarding, and governance, while dynamic models handle finer variations. section 6.0

A mixed authorization strategy

ACME retains RBAC for broad job responsibilities, uses ReBAC so Alice can access documents where she is a viewer, editor, or owner, and applies ABAC so Bob’s customer-data access depends on region and record sensitivity. Carol gains fewer exceptions and better visibility into why access is granted. section 6.0

Dynamic models complement rather than replace static models. Their operational value depends on policies that remain aligned with identity data, resource metadata, business intent, security requirements, and audit needs. section 6.0 section 1.0

How Authorization in Action covers it

How deep it goes
Contrasts static and dynamic approaches and illustrates RBAC, ReBAC, and ABAC, but stops short of implementation syntax.
Examples
Uses document ownership relationships, regional and clearance attributes, record sensitivity, time of day, and enterprise access exceptions.
What it assumes
Assumes basic authorization and identity concepts while establishing why static permissions and roles become insufficient as systems scale.
What you can do after
Evaluate when to combine RBAC with ReBAC or ABAC in flexible, auditable, business-aligned authorization systems.
How it connects
Connects authorization with identity, policies, resources, relationships, context, RBAC, ReBAC, ABAC, auditability, and governance.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Authorization in Action. The section links point to the parts of the book it draws on.