Workspace-level permissions that carry down to every project and asset
A hierarchical access model in which permissions granted on a workspace or project apply to everything inside it, checked on every request.
- Partner
- A multinational professional services firm
- Period
- October 2024 to January 2026
- Access rules
- 9
- Direct, group, ownership and action rank, each with inheritance, plus parent read
- Token types
- 3
- Entra ID, service-to-service and short-lived WebSocket
- Top of the hierarchy
- Workspace
- Projects, then pipelines, agents, dashboards and endpoints
The challenge
Teams share some work and keep other work private. Assigning access asset by asset does not work when each project contains many pipelines, agents, dashboards and versions.
What we built
A Casbin policy model that follows the platform's resource hierarchy. Access can come from a direct grant, a group, ownership, a higher action or a parent resource, and every request is checked after the caller's identity is verified.
What was delivered
- Permissions inherited from workspace to project to asset
- Group-based access and ownership rules
- Identity verified for users, services and WebSocket connections
Partner background
Our partner is a multinational professional services firm whose teams work with large volumes of documents, spreadsheets, databases and email. It wanted one internal platform where those teams could build data pipelines and AI agents themselves, instead of commissioning a new application for each need. The platform had to run inside the partner's Microsoft 365 and Azure environment, keep each team's work separate, and move work from experiment to production through controlled environments.
The challenge
Too many assets to manage one by one
Each project holds pipelines, agents, dashboards, endpoints and their versions. Granting access to each separately is slow and error prone.
Different kinds of callers
Requests come from users in the browser, from other services and over long-lived WebSocket connections.
Navigation needs context
A user with access to one pipeline still needs to see the project and workspace that contain it.
Objectives
- Grant access once at the right level and have it apply below
- Support groups and ownership
- Rank actions so a broader permission covers a narrower one
- Verify every caller's identity before checking permissions
Our role
CharCentric provided technical leadership and architecture within a multidisciplinary engineering team, and contributed directly to implementation. The platform was built over 16 months, from October 2024 to January 2026, as a Python and FastAPI backend on Azure.
Scope and timeline
The authorization model and token handling were built between March and July 2025.
Approach
Model the hierarchy explicitly
Resources are linked child to parent in the policy store: assets to projects, projects to workspaces. A policy on a parent applies to its children.
Rank actions
Actions are ordered, so a user allowed to manage a resource is also allowed to read it.
Separate identity from permission
Middleware verifies identity first, through an HTTP or WebSocket strategy. The policy check then answers a single question: can this subject perform this action on this resource?
Implementation
Policy model
Requests are evaluated as subject, object and action. Rules cover direct access, group access, ownership, action hierarchy, parent inheritance and reading a parent when a child is accessible.
Policy storage
Policies are stored in PostgreSQL through an asynchronous Casbin adapter.
Identity
Users authenticate with Microsoft Entra ID tokens. Services use machine-to-machine tokens. WebSocket connections use short-lived authorization tokens issued by the platform.
Tools and technologies
| Tool | Purpose |
|---|---|
| Casbin | Policy model and enforcement |
| PostgreSQL | Policy storage |
| Microsoft Entra ID | User identity |
| FastAPI middleware | Identity verification |
| SQLAlchemy | Asynchronous policy adapter |
What was delivered
- Access rules
- 9
- Hierarchy levels
- 4
- Token types
- 3
- Policy model
- 1
- A hierarchical permission model applied to every request
- Group, ownership and action-rank rules
- Identity verification for users, services and WebSockets
- Parent visibility for users with access to a child resource
Why it matters
Access control that matches how an organization actually groups its work is easier to administer and harder to get wrong. Modelling the hierarchy once avoids thousands of individual grants.
If your organization is planning a platform of this kind, or needs a specific part of one designed and delivered, we would be glad to discuss it.