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