Identités, permissions et isolation multi-tenant

Le socle sépare quatre questions qui sont souvent mélangées : qui appelle, quelle action est demandée, dans quel tenant, et sur quel projet ou enregistrement. Une requête doit franchir ces contrôles avant d'atteindre le cas d'usage.

Authentifier une personne ou un système

Le parcours navigateur utilise des jetons d'accès courts et des jetons de renouvellement conservés côté serveur. Les refresh tokens peuvent être révoqués et sont associés au contexte de session. Les mots de passe sont hachés avec Argon2, les échecs répétés peuvent verrouiller temporairement un compte et le temps de vérification est égalisé pour limiter l'énumération d'utilisateurs.

Le même socle accepte des fournisseurs SSO OIDC ou SAML. Leur présence ne signifie pas qu'un fournisseur est déjà configuré : métadonnées, certificats, claims et politique de connexion restent propres au client.

Pour une intégration machine, une clé API porte une liste d'actions autorisées. Elle peut donc recevoir un sous-ensemble des droits de son créateur, et éventuellement être limitée à un projet.

Nommer les actions avec des capabilities

Une capability décrit une action, par exemple users:list ou documents:upload. Un rôle regroupe des capabilities exactes ou des motifs. Un groupe confère un ou plusieurs rôles à ses membres.

Les rôles intégrés couvrent l'administration et l'usage standard. Des rôles et groupes propres au tenant peuvent compléter ce socle lorsque l'application expose les écrans correspondants.

Ajouter des règles contextuelles de type ABAC

Le RBAC répond à « ce rôle peut-il effectuer cette action ? ». Certaines décisions demandent aussi « sur quelle ressource ? ». Le garde d'accès projet combine alors plusieurs attributs : tenant courant, groupes, projets accessibles, scope de la clé, projet de l'agent et type de principal.

Un repository métier peut ajouter un prédicat dynamique, par exemple « seulement les dossiers dont l'utilisateur est responsable ». Cette extension est volontairement locale au domaine. Le socle ne prétend pas fournir un moteur universel de politiques ABAC.

Isoler les tenants et les projets

Le tenantId est propagé dans le contexte de requête. Les repositories tenant-aware l'exigent dans leurs opérations et l'ajoutent aux clauses SQL. Les droits projet se superposent à cette première frontière.

Ce mécanisme réduit fortement le risque qu'un identifiant valide dans un tenant donne accès au même identifiant dans un autre. Les tests d'API incluent systématiquement des tentatives cross-tenant, y compris pour les requêtes ad hoc qui ne passent pas par un repository tenant-aware.

Une décision vérifiable

Une matrice de sécurité utile couvre au minimum :

• personne, clé API et agent ;
• rôle autorisé et rôle refusé ;
• tenant courant et tenant étranger ;
• projet accessible et projet inaccessible ;
• action autorisée et action hors scope.

Cette matrice devient un plan de tests, pas seulement une convention d'architecture.