Identity and RBAC

Introduction 

 The CMS implements it's own authentication flows as well as leveraging federated authentication with both Microsoft and Google. 

 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). 

 

 Supported Roles 

 

 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.