# 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](/content/blog/what-is-fine-grained-authorization/index.html) 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., `[\