2.3 KiB
Authorization Architecture
Two Axes
- Identity / role — who is the actor?
- Entitlement / feature — what is the tenant allowed to use on their plan?
Both must pass for protected business actions.
Platform & Workspace Roles (Core)
| Role | Scope |
|---|---|
platform_admin |
Cross-tenant platform administration (bypass workspace role checks) |
tenant_owner |
Full workspace control; required for complete onboarding |
tenant_admin |
Manage branding/domain/members (as implemented) |
tenant_editor |
Content/edit capabilities |
tenant_viewer |
Read-only |
Source of truth: core_platform_db.tenant_memberships (ADR-007).
Identity-Layer Roles
identity_access_db.tenant_memberships uses simpler roles (tenant_admin / tenant_member) for SSO listing — not operational authz.
Entitlement
Feature keys: {service_key}.{resource}.{action}
Example: accounting.invoice.create, payment.module.enabled, payment.requests.create
Check: POST /api/v1/tenants/{tenant_id}/features/check
Cached in Redis; custom tenant overrides beat plan defaults.
Payment module (Torbat Pay): Core L1 key payment.module.enabled. Payment service adds L2 bundles and L3 feature toggles in payment_db — see ADR-021 and payment-contracts.md. Payment must not compute Core plan entitlements locally.
Workspace module (Torbat Workspace): Planned Core L1 key workspace.module.enabled. Permission tree workspace.* is owned by the Workspace Platform (workspace_db) — see ADR-024 and workspace-roadmap.md. This is not Core Tenant Workspace membership. Workspace must not compute Core plan entitlements locally.
API Guards (Core)
Configurable AUTH_REQUIRED. Dependencies such as require_authenticated, require_platform_admin, require_tenant_admin, MembershipService.ensure_role.
Future
Custom permission trees, invites, and finer RBAC are planned — track in module-registry.md and roadmap.md.