Authentication and Users
Authentication and Users
Overview
Authentication controls how users sign in, complete activation, register MFA, use federated login, and receive role-scoped access to CMS.
Sign-In Methods
CMS supports local CMS login and federated login through Microsoft Entra or Google when those providers are enabled in settings. Federated provider challenge routes enforce the same enablement settings shown in the login UI.
Microsoft Entra validation can be restricted to a configured tenant by setting AzureAdTenantId. When that setting is blank, the existing multi-tenant Entra behaviour is preserved.
Activation
Users can be created with activation fields including activation code, expiry, and email confirmation state.
Supported activation actions include:
| Action | Behaviour |
|---|---|
| Send welcome email | Platform administrators can send a welcome email with an activation link. |
| Reset activation | Administrators can generate a fresh one-hour activation code for an unconfirmed user. |
| Request activation code | A user who can authenticate but is not activated can request a new code from the login activation form. |
| Activate account | The /activate portal page submits the activation code and completes activation. |
Manual Review Required: User creation generates activation data but does not automatically send welcome or activation email. Operators should send the welcome email or reset activation where needed.
MFA
MFA registration is shown only when MFA is required and the user is not already registered. Resetting MFA clears the stored registration, secret, and QR code so the user re-registers on the next MFA-required sign-in.
Tenant administrators can reset MFA enrollment for users in their own tenant. Broader user administrators can reset MFA only inside their permitted hierarchy.
User Management
The Users page is available to administrator roles. Platform roles access it under Administration, while tenant, partner, and distributor administrators access the scoped Settings group.
The user editor includes:
- User properties.
- Scope and permissions.
- Authentication settings.
- Authentication information.
- Activation reset.
- MFA reset.
- Password reset.
Role Assignment
Administrator roles can only assign roles within their permitted hierarchy.
| Acting role | Typical assignment boundary |
|---|---|
| Platform administrator | Platform, distributor, partner, and tenant roles. |
| Distributor administrator | Distributor, partner, and tenant roles in distributor scope. |
| Partner administrator | Partner and tenant roles in partner scope. |
| Tenant administrator | Tenant roles in tenant scope. |
Platform readers have read access where allowed but cannot create, update, delete, reset activation codes, or reset passwords.
Timezone Preference
JWTs include the user's TimeZoneId claim. Users can update their own timezone through the current-user timezone API without broader user administration permissions.
Blank timezone values inherit the Platform > General SystemTimeZoneId setting. Invalid saved values are rejected on save or treated as UTC for display fallback.
Email Templates
Activation, welcome, invoice, delinquent payment, budget alert, new subscription, and recover account templates are stored in the NotificationTemplates table and managed from Administration > Notifications.
Implementation Gap:
NewSubscriptionandRecoverAccounttemplates appear to be placeholders and are not confirmed as active send flows. Password reset changes passwords directly and does not send a recover email.
Security and Scoping
Portal UI claims are not the authorization boundary. Federated login exchanges identity-provider tokens for CMS-issued JWTs, and API routes enforce role and hierarchy checks server-side.
The portal no longer logs refresh token values and does not store federated access tokens in plain browser local storage.