Identity and RBAC
Purpose
Explains how authentication and authorization work across the hierarchy, and how the CMS enforces least-privilege access.
Authentication
- Supports CMS credentials and federated sign-in (e.g., Microsoft Entra).
- Tokens are validated for issuer, audience, lifetime, and signature.
- Federation settings control whether CMS login and/or Entra/Google login are allowed.
Authorization model
- Role-based access control with built-in roles aligned to the hierarchy.
- Access is scoped to the entity where the role is granted (platform, distributor, partner, tenant).
Common roles (illustrative):
- PlatformAdministrator / PlatformReader / PlatformService
- DistributorAdministrator / DistributorReader
- PartnerAdministrator / PartnerReader
- TenantAdministrator / TenantUser
Scope and inheritance
- Roles do not leap across unrelated branches. A Partner admin cannot see a Tenant owned by a different Partner.
- Platform roles supersede lower scopes for operations and support.
Audit and accountability
- All sensitive actions (pricing, commission, usage processing, role assignment) should be traceable to an authenticated identity.
- Logs and audit trails enable operational forensics and compliance reporting.
Federation controls (examples)
- Settings can enable/disable specific identity paths (e.g., allow Entra only). First
- First-login checks should enforce MFA requirements and password change where applicable.