Topic starter
12/06/2026 9:13 pm
TL;DR: Two ways to handle hierarchy-based permissions in multi-tenant applications are shown by Cerbos, using policy-defined roles or dynamic attributes to express descendant and child access in ABAC and ReBAC patterns. The governance challenge is not the syntax of the policy, but whether authorization logic stays auditable as tenant and resource hierarchies grow.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Mastering hierarchy-based permissions with Cerbos - Policy-defined roles vs. dynamic attributes”.
Key questions
Q: How should security teams govern hierarchy-based access in multi-tenant applications?
A: Start by treating the resource hierarchy as a governed entitlement model, not a coding shortcut.
Q: Why do hierarchy-based access rules become risky as tenant structures grow?
A: They become risky when business hierarchies start standing in for approved entitlement boundaries.
Q: What is the difference between policy-defined roles and attribute-driven authorization?
A: Policy-defined roles encode hierarchy logic directly in named role rules, which makes the model easier to inspect but harder to scale.
Practitioner guidance
- Define hierarchy semantics before policy authoring Specify what counts as self, child, immediate child, and descendant for each resource tree so policy authors do not improvise different meanings in different roles.
- Separate tenant isolation from hierarchy traversal Keep a distinct deny rule for tenant boundaries and a separate allow path for descendant access, then test them independently during review.
- Choose the governance home for access logic Decide whether hierarchy rules belong in static role policies or runtime principal attributes, and document who approves changes to each layer.
Bottom line: Hierarchy-based authorization is an IAM governance problem because access scope, hierarchy depth, and tenant boundary control all have to stay auditable together.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/06/2026 11:07 pm
Hierarchy-based authorization is an IAM governance problem before it is a policy language problem. The article shows that the hard part is not whether the engine can evaluate descendant relationships, but whether those relationships remain comprehensible, auditable, and stable as business structures change. That is an identity governance question because the access model has to survive organisational growth, role drift, and tenant expansion without becoming opaque. Practitioners should judge the model by governance durability, not syntax convenience.
A question worth separating out:
Q: How do teams prevent tenant isolation from breaking in hierarchical access models?
A: Use a separate deny rule for tenant boundaries and do not rely on hierarchy checks to imply isolation. Resource trees can look structurally similar across customers while belonging to different tenants, so the policy must enforce scope independently. That separation is what keeps descendant access from becoming cross-tenant exposure.
👉 Read our full editorial: Hierarchy-based authorization is still an IAM governance problem