The authorization model

01Identity does not decide rights #sec_877062d8

The identity provider — Entra ID, Okta, Google, ADFS or another IdP — answers one question: who has just authenticated, and with what level of assurance? REVIEWIT answers the following questions: what can this person do, within what scope and until when?

This separation prevents a customer directory administrator from assigning themselves an internal role within the platform. The groups or roles sent by an IdP do not automatically become REVIEWIT permissions. They can contribute to identification, but the access decision remains made, administered, audited and revoked within REVIEWIT.

The pivot identifier is stable and independent of the email address or display name. A change of IdP, name or organization must neither recreate rights nor make history illegible.

02Three closed scopes #sec_5953283d

The model distinguishes three levels that never merge.

The platform. The Platform Operator role is reserved for the publisher. It allows the service to be operated, without giving any rights in a customer’s data beyond explicitly planned operations.

The subscription. The Subscription Admin governs a subscription identified by its public identifier: common parameters, workspaces, roles and subscribed capabilities. Its power does not extend to other subscriptions.

The workspace. The Manager, Reader, Reporting Reader and Auditor roles are exercised on a specific workspace. They are resolved from the database at the time the application needs them, in order to reflect a revocation or expiration without carrying all rights in a long session.

This taxonomy is closed by design. Adding a platform or subscription role is not a simple configuration operation: it is a model decision that must define its scope, administration and audit impact.

No administration role confers the right to make a review decision. The Review Manager role and campaign assignments respond to a distinct business model. Administering the container does not mean deciding on behalf of the reviewer.

03The context is resolved server-side #sec_f2e08188

A client request cannot impose its own subscription or workspace. The application resolves the authorized context on the server side, based on identity and active memberships. An identifier provided in a URL or form remains a requested target, never a proof of authorization.

Rights are versioned. When a role is assigned, suspended, revoked or expired, an authorization version evolves. Sessions and applications can then detect that their information is no longer current and re-evaluate effective rights.

Each membership has a status, a grant date, an author, a reason and an expiration. A temporary suspension is distinguished from a definitive revocation. The model therefore makes both the current right and its life cycle visible.

The management of the "last administrator" applies a fail-closed guard: a subscription cannot be left without an active manager due to a concurrent deletion or an ill-prepared expiration. The rule applies to actually effective rights, not just the number of lines present.

04Bootstrap, elevation and emergency access #sec_b168e1cb

The first administrator of a subscription must be established by an explicit and traceable procedure. This bootstrap is not a permanent shortcut: once governance is installed, administrators are managed according to the same rules as other memberships.

Sensitive operations may require TrustGate elevation, i.e. recent or stronger authentication. Elevation confirms the identity of the actor at the critical moment; it does not invent any role for him. Authorization is evaluated before and after elevation.

Break-glass is an exceptional operating posture, not a hidden client role. It is time-bound, motivated, monitored and audited. It is never used to silently bypass a subscription’s authorization model.

05A revocation that propagates and demonstrates #sec_812968cd

Any assignment, suspension, expiration and revocation produces an act in the Audit Trail with its actor, its reason and its scope. A change in rights is not just a configuration change: it is a security event.

Propagation combines several mechanisms: versioning of roles, reading of effective memberships and resolution in the database of workspace rights. The objective is not to trust a cookie until it expires, but to reduce the window during which a session could continue to carry false information.

Periodic reconciliation finally checks completeness: declared rights, issued sessions and active accounts must tell the same story. A divergence becomes a visible incident rather than an implicit permission.

06In summary #sec_e0f5ace1

The REVIEWIT authorization model is based on an easy-to-remember rule: the IdP proves identity; REVIEWIT owns the rights. Three closed scopes, a context resolved on the server side, versioned roles and systematic traceability prevent privileges from traveling further or longer than expected.