Rôles & RBAC

Sovrium utilise le contrôle d'accès basé sur les rôles (RBAC) avec une couche optionnelle de groupes. 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 référencent les rôles pour contrôler la création/lecture/mise à jour/suppression et l'accès par champ.

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 :

auth:
  roles:
    - name: editor
      level: 30 # between viewer (10) and member (40)
    - name: moderator
      level: 50 # between member (40) and admin (80)

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.

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.

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.
`pickerLanding`	Repli multi-enregistrements pour un `defaultLanding` à modèle. Voir Atterrissage après connexion.

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 (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.

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`.

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 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 — les rôles par défaut en contexte.
Groupes — appartenance plusieurs-à-plusieurs ajoutée par-dessus les rôles.
Atterrissage après connexion — règles d'atterrissage par rôle.
Permissions de table — là où les rôles contrôlent réellement les données.

← PreviousStratégies Next →Groupes