Le modèle d'autorisation
01L'identité ne décide pas des droits #sec_877062d8
Le fournisseur d'identité — Entra ID, Okta, Google, ADFS ou un autre IdP — répond à une question : qui vient de s'authentifier, et avec quel niveau d'assurance ? REVIEWIT répond aux questions suivantes : que peut faire cette personne, dans quel périmètre et jusqu'à quand ?
Cette séparation empêche qu'un administrateur d'annuaire client puisse s'attribuer lui-même un rôle interne à la plateforme. Les groupes ou rôles envoyés par un IdP ne deviennent pas automatiquement des autorisations REVIEWIT. Ils peuvent contribuer à l'identification, mais la décision d'accès reste portée, administrée, auditée et révoquée dans REVIEWIT.
L'identifiant pivot est stable et indépendant de l'adresse de courrier ou du nom affiché. Un changement d'IdP, de nom ou d'organisation ne doit ni recréer les droits ni rendre l'historique illisible.
02Trois portées fermées #sec_5953283d
Le modèle distingue trois niveaux qui ne se confondent jamais.
La plateforme. Le rôle Platform Operator est réservé à l'éditeur. Il permet d'exploiter le service, sans donner de droit dans les données d'un client au-delà des opérations explicitement prévues.
La souscription. Le Subscription Admin gouverne une souscription identifiée par son identifiant public : paramètres communs, workspaces, rôles et capacités souscrites. Son pouvoir ne s'étend pas aux autres souscriptions.
Le workspace. Les rôles Manager, Reader, Reporting Reader et Auditor s'exercent sur un workspace précis. Ils sont résolus depuis la base au moment où l'application en a besoin, de façon à refléter une révocation ou une expiration sans transporter tous les droits dans une session longue.
Cette taxonomie est fermée par construction. Ajouter un rôle plateforme ou souscription n'est pas une simple opération de configuration : c'est une décision de modèle qui doit définir son périmètre, son administration et son impact d'audit.
Aucun rôle d'administration ne confère le droit de prendre une décision de revue. Le rôle de Review Manager et les assignations de campagne répondent à un modèle métier distinct. Administrer le contenant ne signifie pas décider à la place du reviewer.
03Le contexte est résolu côté serveur #sec_f2e08188
Une requête cliente ne peut pas imposer sa propre souscription ou son propre workspace. L'application résout le contexte autorisé côté serveur, à partir de l'identité et des memberships actifs. Un identifiant fourni dans une URL ou un formulaire reste une cible demandée, jamais une preuve d'autorisation.
Les droits sont versionnés. Lorsqu'un rôle est attribué, suspendu, révoqué ou expiré, une version d'autorisation évolue. Les sessions et applications peuvent alors détecter que leurs informations ne sont plus courantes et réévaluer les droits effectifs.
Chaque membership possède un état, une date d'octroi, un auteur, un motif et une expiration. Une suspension temporaire se distingue d'une révocation définitive. Le modèle rend donc visibles à la fois le droit courant et son cycle de vie.
La gestion du « dernier administrateur » applique une garde fail-closed : une souscription ne peut pas se retrouver sans responsable actif à cause d'une suppression concurrente ou d'une expiration mal préparée. La règle porte sur les droits réellement effectifs, pas seulement sur le nombre de lignes présentes.
04Bootstrap, élévation et accès d'urgence #sec_b168e1cb
Le premier administrateur d'une souscription doit être établi par une procédure explicite et traçable. Ce bootstrap n'est pas un raccourci permanent : une fois la gouvernance installée, les administrateurs se gèrent selon les mêmes règles que les autres memberships.
Les opérations sensibles peuvent exiger une élévation TrustGate, c'est-à-dire une authentification récente ou plus forte. L'élévation confirme l'identité de l'acteur au moment critique ; elle ne lui invente aucun rôle. L'autorisation est évaluée avant et après l'élévation.
Le break-glass est une posture d'exploitation exceptionnelle, pas un rôle client caché. Il est borné dans le temps, motivé, surveillé et audité. Il ne sert jamais à contourner silencieusement le modèle d'autorisation d'une souscription.
05Une révocation qui se propage et se démontre #sec_812968cd
Toute attribution, suspension, expiration et révocation produit un acte dans l'Audit Trail avec son acteur, son motif et son périmètre. Une modification des droits n'est pas seulement un changement de configuration : c'est un événement de sécurité.
La propagation combine plusieurs mécanismes : version des rôles, lecture des memberships effectifs et résolution en base des droits de workspace. L'objectif n'est pas de faire confiance à un cookie jusqu'à son expiration, mais de réduire la fenêtre pendant laquelle une session pourrait continuer à porter une information devenue fausse.
Le rapprochement périodique vérifie enfin la complétude : les droits déclarés, les sessions émises et les comptes actifs doivent raconter la même situation. Une divergence devient un incident visible plutôt qu'une permission implicite.
06En résumé #sec_e0f5ace1
Le modèle d'autorisation REVIEWIT repose sur une règle facile à retenir : l'IdP prouve l'identité ; REVIEWIT possède les droits . Trois portées fermées, un contexte résolu côté serveur, des rôles versionnés et une traçabilité systématique empêchent les privilèges de voyager plus loin ou plus longtemps que prévu.