Mastering hierarchy-based permissions with Cerbos - Policy-defined roles vs. dynamic attributes

Effective Identity and Access Management is critical for modern applications, and a core component of IAM is authorization. Handling permissions becomes especially complex in applications with hierarchical data, like organizational structures, geographical regions, or product categories. This is a classic challenge in achieving fine-grained authorization.

Users often need access not just to a specific node in the hierarchy but also to its descendants or immediate children, a pattern often addressed by Relationship-Based Access Control (ReBAC). Cerbos, an open source, stateless authorization layer, provides powerful and flexible ways to manage such scenarios through Policy-Based Access Control (PBAC).

In this post, we'll explore two approaches to implementing hierarchy-based permissions in Cerbos, inspired by a real-world use case for a data analytics platform. Both methods leverage Attribute-Based Access Control (ABAC), but differ in their implementation strategy:

1. Policy-defined roles with attribute-based conditions. Defining explicit role policies for each tenant where hierarchical logic is hardcoded inside the policy.
2. Dynamic, attribute-driven generic policies. Shifting the hierarchical conditions entirely to the principal's attributes and using a single, generic policy for interpretation.

The use case. Multi-tenant data analytics platform

Imagine a platform that provides data analytics services. This platform is multi-tenant, meaning different client companies (tenants) use it. Each tenant has its own users, roles, and data, which is categorized by attributes like geography (e.g., Global > Europe > Germany > Berlin) and businessUnit (e.g., AlphaOrg > Sales > EMEA_Sales).

Key fine-grained authorization requirements include:

• Restricting data visibility based on a user's role within their tenant.
• Allowing users to see data for their specific hierarchical node and potentially its descendants or children - a core ReBAC problem.
• Ensuring strict data isolation between tenants.

Setting the stage. Principals, resources, and hierarchies

In Cerbos, we define:

• Principals. The actors in the system (users, services). They have an ID, roles, and attributes.
• Resources. The objects principals interact with. In our case, a generic dataRecord resource representing a piece of analyzable data.
• Policies. The rules that determine what actions a principal can perform on a resource. These policies are the foundation of a PBAC system.

Our dataRecord resource will have attributes like:

• geography. An array representing its geographical hierarchy (e.g., ["Global", "Europe", "Germany", "Berlin"]).
• businessUnit. An array representing its organizational hierarchy (e.g., `[\