Role-Based Access Control

CET2's authorization model is deny-by-default: a signed-in user can do nothing until an administrator explicitly grants them a role scoped to a tenant. There is no implicit access from being a member of a customer's Entra tenant — sign-in and authorization are two separate steps.

Roles

Roles are a fixed set of permission bundles, defined in code (not customer-editable) — but the assignments of principals to roles are fully dynamic and stored per-deployment.

Role	Typical use	Notable permissions
Read Only	Auditors, reporting	View devices, users, apps, compliance, reports
Service Desk Analyst	Frontline support	Above, plus device sync, BitLocker view
Endpoint Administrator	Device/Intune ops	Device + app management, compliance management
Security Administrator	Security team	Defender/security posture, BitLocker management
Customer Administrator	The customer's own IT lead	Full administration within their tenant, including managing their own RBAC assignments
MSP Engineer	Cross-customer support	Support + automation across every assigned customer
MSP Administrator	MSP leadership	Cross-tenant administration, tenant onboarding, RBAC management
Platform Super Administrator	Platform owner	Every permission, every tenant

Scope

Every role assignment has a scope:

• Global — reaches every tenant CET2 knows about. Reserved for MSP/platform roles.
• Tenant-scoped — reaches only the tenant(s) explicitly listed. This is how a customer administrator is confined to seeing and managing only their own organisation.

A permission check is always HasPermission(principal, permission, tenantId); it returns true only if an assignment exists whose scope covers that specific tenant (or is Global).

What this means in practice

• GET /api/tenants returns only the tenants the caller's assignments cover — an unprovisioned user gets an empty list, not an error.
• Every per-tenant endpoint is gated on the route's tenantId — a customer user can never reach another customer's data by guessing a tenant ID in the URL.
• Sensitive Graph writes (disabling a user, issuing a Temporary Access Pass) additionally require the CET2 Data application's service principal to hold a directory role (User Administrator / Authentication Administrator) in that specific customer tenant — a Graph permission alone is not enough for these "sensitive actions" as classified by Microsoft Graph. See Graph Permissions.
• Admin accounts are protected — even with User Administrator, CET2 cannot disable a user who themselves holds a directory role; the UI surfaces this before the action is attempted.

Assigning a role

1. Sign in as an administrator with RBAC.Manage (Customer Administrator, MSP Administrator, or Platform Super Administrator).
2. Go to Access Control.
3. Look up the user or group by name — the lookup searches the relevant tenant's directory.
4. Choose a role and a scope (a specific tenant, or Global for MSP staff).
5. Save. The change takes effect on the target's next token refresh (typically within a few minutes, or immediately on their next sign-in).