RBAC Model
The Enterprise Stack uses Role-Based Access Control (RBAC) to authorize access to APIs and administrative operations.
RBAC in the Enterprise Stack is built around four core concepts:
| Concept | Description |
|---|---|
| Permissions | Individual operations that can be performed |
| Roles | Collections of permissions |
| Principals | Identities such as Accounts, API Keys, or external users |
| Scopes | Organizational boundaries where roles apply |
Permissions are grouped into roles, and roles are assigned to principals.
Principal → Role → Permissions → API Access
Permission Scope
Roles are always assigned within a scope. Scopes define where permissions are effective.
| Scope | Description |
|---|---|
| Organization | Access across all tenants in an organization |
| Tenant | Access limited to one tenant |
| Sub-tenant | Access limited to nested tenant structures |
| Service | Access limited to a specific service instance |
Example: A Tenant Admin role assigned in Tenant A can manage resources in Tenant A, but not in Tenant B.
Example Role Setup
Typical enterprise deployments use role profiles similar to:
| Role | Permissions |
|---|---|
| Organization Admin | Manage tenants, services, and users |
| Tenant Admin | Manage services within a tenant |
| Issuer Operator | Issue and revoke credentials |
| Verifier Operator | Verify credentials |
| Auditor | Read-only access to logs and analytics |
Roles can be assigned to:
- Accounts
- API keys
- External IAM identities (after successful authentication)
Example Authorization Flow
- A principal authenticates (account, API key, or IAM token)
- Enterprise Stack validates identity
- RBAC roles are resolved for the target scope
- Requested operation is mapped to a required permission
- Permission is granted or denied
If the permission is not present, the request is rejected with 403 Forbidden.
Related
Last updated on March 10, 2026