# Rôles & RBAC Sovrium utilise le **contrôle d'accès basé sur les rôles (RBAC)** avec une couche optionnelle de [groupes](/fr/docs/auth-groups). Chaque utilisateur authentifié possède exactement un rôle ; les rôles sont organisés selon une **hiérarchie** numérique ; et les [permissions de table](/fr/docs/table-permissions) référencent les rôles pour contrôler la création/lecture/mise à jour/suppression et l'accès par champ. ```yaml auth: strategies: - type: emailAndPassword defaultRole: member roles: - name: editor description: Can edit content level: 30 ``` ## Rôles intégrés Trois rôles sont fournis avec chaque application dont l'authentification est activée. Ils sont toujours disponibles et **ne peuvent pas être redéfinis** par des rôles personnalisés. | Rôle | Niveau | Accès | | -------- | ------ | --------------------------------------------------------------------------------------------- | | `admin` | 80 | Accès complet — gérer les utilisateurs, les rôles et les paramètres ; toutes les permissions. | | `member` | 40 | Accès standard aux ressources de l'application. | | `viewer` | 10 | Accès en lecture seule. | ## Hiérarchie & niveaux de rôle Chaque rôle possède un `level` numérique. Les niveaux plus élevés sont plus privilégiés. Le niveau établit un ordre utilisé par la résolution des permissions et par les fonctionnalités qui comparent l'ancienneté des rôles (par exemple, un rôle équivalent à un administrateur est celui qui se situe au niveau configuré le plus élevé). Les niveaux intégrés sont fixés à `admin=80`, `member=40`, `viewer=10`. Les rôles personnalisés s'insèrent n'importe où sur cette échelle via leur propre `level` : ```yaml auth: roles: - name: editor level: 30 # between viewer (10) and member (40) - name: moderator level: 50 # between member (40) and admin (80) ``` :::callout **Le plus permissif l'emporte.** Lorsque les permissions d'un utilisateur proviennent de plusieurs sources (son rôle et ses groupes), c'est l'union des opérations accordées qui s'applique. Si le rôle accorde `read` et qu'un groupe accorde `update`, l'utilisateur obtient les deux. Voir [Groupes](/fr/docs/auth-groups). ::: ## Définitions de rôles personnalisés `auth.roles` est un tableau de définitions de rôles personnalisés ajoutées par-dessus les rôles intégrés. Un tableau vide (ou l'omission du champ) signifie que seuls les rôles intégrés existent. ```yaml auth: roles: - name: editor description: Can edit content level: 30 - name: moderator level: 20 - name: contributor ``` | Propriété | Description | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | **Obligatoire.** Identifiant du rôle. Minuscules, alphanumérique, traits d'union ; doit commencer par une lettre. Doit être unique et ne doit pas entrer en conflit avec le nom d'un rôle intégré ou d'un groupe. | | `description` | Description lisible de la finalité du rôle. | | `level` | Niveau de hiérarchie (plus élevé = plus privilégié). Références intégrées : `admin=80`, `member=40`, `viewer=10`. | | `defaultLanding` | URL d'atterrissage après connexion par rôle. Voir [Atterrissage après connexion](/fr/docs/auth-post-login). | | `pickerLanding` | Repli multi-enregistrements pour un `defaultLanding` à modèle. Voir [Atterrissage après connexion](/fr/docs/auth-post-login). | **Règles de nommage** — les noms de rôle correspondent à `^[a-z][a-z0-9-]*$` : | Nom | Valide ? | Raison | | ----------------- | -------- | ----------------------------- | | `editor` | ✅ | lettres minuscules | | `content-manager` | ✅ | trait d'union autorisé | | `Editor` | ❌ | majuscule non autorisée | | `123role` | ❌ | doit commencer par une lettre | La validation rejette : - Les noms de rôle personnalisés en double. - Les noms personnalisés qui entrent en conflit avec les rôles intégrés (`admin`, `member`, `viewer`). - Les noms personnalisés qui entrent en conflit avec un nom de [groupe](/fr/docs/auth-groups) (les rôles et les groupes partagent un espace de noms). ## Rôle par défaut `auth.defaultRole` est le rôle attribué aux nouveaux utilisateurs lors de leur inscription. Il vaut `member` par défaut lorsqu'il est omis, et doit référencer un rôle intégré **ou** un rôle personnalisé défini dans `auth.roles`. ```yaml auth: strategies: - type: emailAndPassword defaultRole: viewer # new users start read-only roles: - name: editor level: 30 ``` | Propriété | Description | | ------------- | ------------------------------------------------------------------------------------------------------ | | `defaultRole` | Rôle accordé aux utilisateurs nouvellement inscrits. Nom intégré ou personnalisé. Par défaut `member`. | :::callout Un `defaultRole` référençant un rôle personnalisé non défini échoue à la validation au démarrage. Définissez le rôle dans `auth.roles` avant de le nommer comme rôle par défaut. Définir `defaultRole: viewer` est un schéma courant pour les applications où les nouveaux utilisateurs doivent rester en lecture seule jusqu'à ce qu'un administrateur les promeuve. ::: ## Rôles administrateur Lorsque `auth` est configuré, la surface de gestion administrateur des utilisateurs est toujours montée (il n'y a pas de bascule distincte). Le **premier utilisateur à s'inscrire devient administrateur** (`firstUserAdmin`). Les administrateurs peuvent : - Créer des utilisateurs (`POST /api/auth/admin/create-user`) — y compris lorsque `allowSignUp: false`. - Inviter des utilisateurs avec des jetons à usage unique (`POST /api/auth/admin/invite-user`). - Attribuer et modifier des rôles. - Usurper l'identité d'utilisateurs pour les flux de support. - Bannir / débannir des utilisateurs. Le rôle du niveau le plus élevé est traité comme équivalent à un administrateur pour ces vérifications, de sorte qu'un rôle personnalisé à `level: 80` (ou plus) participe au contrôle d'administration aux côtés du rôle intégré `admin`. ## Comment les rôles contrôlent les données Les rôles n'accordent pas l'accès aux données par eux-mêmes — ils sont référencés par le bloc `permissions` de chaque table. Un rôle sans entrée de permission correspondante n'a aucun accès à cette table. Voir [Permissions de table](/fr/docs/table-permissions) pour le modèle complet de création/lecture/mise à jour/suppression/restauration/commentaire et par champ, y compris la façon dont les entrées préfixées par `group:` se combinent avec les rôles. ## Pages associées - [Présentation de l'authentification](/fr/docs/auth-overview) — les rôles par défaut en contexte. - [Groupes](/fr/docs/auth-groups) — appartenance plusieurs-à-plusieurs ajoutée par-dessus les rôles. - [Atterrissage après connexion](/fr/docs/auth-post-login) — règles d'atterrissage par rôle. - [Permissions de table](/fr/docs/table-permissions) — là où les rôles contrôlent réellement les données.