Modèle de permissions
La hiérarchie à trois niveaux utilisée par Scrydon pour déterminer qui peut faire quoi — rôles d'organisation, appartenance directe à un espace de travail et droits basés sur les équipes.
Chaque décision d'autorisation dans Scrydon est résolue via une hiérarchie à trois niveaux. Cette page explique la hiérarchie et la table des rôles qui la sous-tend.
Ordre de résolution
Si oui → accès complet à tous les espaces de travail de l'organisation. Les contrôles au niveau de l'espace de travail sont ignorés.
Si oui → utiliser le rôle de l'acteur dans la portée de l'espace de travail (membre, administrateur, propriétaire).
Si oui → prendre le rôle le plus élevé accordé parmi toutes les appartenances aux équipes qui s'appliquent à cet espace de travail.
→ Accès refusé. Aucun droit implicite. Aucun repli.
Cette même hiérarchie est utilisée par le client (useHasPermission() dans l'interface) et par le serveur (hasPermission() dans les routes API). Les vérifications de rôles en ligne sont interdites — toute décision de permission passe par cette hiérarchie.
Rôles au niveau de l'organisation
| Rôle | Ce qu'ils peuvent faire |
|---|---|
| Admin | Accès complet au niveau de l'organisation. Gérer les espaces de travail, membres, équipes, intégrations, facturation. (Rôle d'appartenance org. le plus élevé — il n'y a pas de niveau « Propriétaire » distinct.) |
| Membre | Aucun pouvoir au niveau de l'organisation. Peut accéder aux espaces de travail via une appartenance directe ou des droits d'équipe. |
Super admins de la plateforme
Un super admin de la plateforme est l'opérateur global d'un déploiement Scrydon — le premier utilisateur créé lors de la configuration, plus toute personne listée dans SUPER_ADMIN_EMAILS ou promue depuis Paramètres → Super admin. Il s'agit d'un rôle au niveau de la plateforme, distinct des rôles d'organisation ci-dessus.
Les super admins de la plateforme sont automatiquement traités comme administrateur d'organisation de chaque organisation. À la connexion, un super admin se voit attribuer (ou, s'il est déjà simple membre, promu à) une appartenance admin de l'organisation sur laquelle il opère, afin que les zones d'administration sous Paramètres → Organisation — membres, équipes, espaces de travail, intégrations, organigramme — se chargent et soient modifiables sans que personne ne les ajoute manuellement à chaque organisation.
Il s'agit d'un droit délibéré du modèle opérateur. Dans une installation auto-hébergée à tenant unique, le super admin est l'opérateur ; si vous faites fonctionner plusieurs organisations sur un même déploiement, traitez le super admin comme un rôle privilégié à l'échelle du déploiement. L'attribution ou la promotion automatique est enregistrée dans le journal d'audit. La suppression d'une organisation est une action opérateur de super admin — l'interface de suppression côté client a été retirée ; la suppression se trouve sous Paramètres → Super admin → Zone dangereuse, effectuée par un opérateur avec le rôle de plateforme super_admin. L'attribution est appliquée à la connexion, donc un super admin nouvellement promu doit se déconnecter et se reconnecter pour en bénéficier.
Rôles au niveau de l'espace de travail
| Rôle | Ce qu'ils peuvent faire |
|---|---|
| Propriétaire | Contrôle total de l'espace de travail. Supprimer, transférer, configurer les intégrations. |
| Admin | Gérer les paramètres, membres, bases de connaissances et intégrations de l'espace de travail. |
| Membre | Utiliser les workflows, exécuter des agents, lire les bases de connaissances selon l'habilitation. |
Droits basés sur les équipes
Les équipes regroupent les utilisateurs au sein de l'organisation. Une équipe peut se voir attribuer un rôle sur un espace de travail, et chaque membre de l'équipe hérite de ce rôle pour cet espace de travail. Un utilisateur peut appartenir à plusieurs équipes ; si deux équipes accordent des rôles différents sur le même espace de travail, c'est le rôle le plus élevé qui s'applique.
Les équipes sont le principal vecteur du provisionnement SCIM — attribuer un groupe à l'application Scrydon dans votre IdP crée/met à jour une équipe correspondante. Voir Identité & Provisionnement.
Habilitation des documents (axe séparé)
La hiérarchie des permissions répond à la question qui peut accéder à cette ressource. L'habilitation des documents est un axe séparé qui répond à la question quels documents de la base de connaissances cet utilisateur est-il autorisé à consulter. L'habilitation est dérivée du rôle d'organisation de l'utilisateur :
| Rôle org. | Habilitation max. | Peut lire |
|---|---|---|
| Membre | RESTRICTED | UNCLASSIFIED, RESTRICTED |
| Admin | CONFIDENTIAL | + CONFIDENTIAL |
Un membre d'espace de travail avec un accès complet à l'espace de travail ne peut toujours pas consulter les documents CONFIDENTIAL de la base de connaissances à moins d'être administrateur de l'organisation. L'accès TOP SECRET est accordé par utilisateur via la table user_clearance (attribution IdP ou intervention admin à quatre yeux) — il n'est pas dérivé d'un niveau de rôle d'organisation. Voir Habilitation de la base de connaissances pour le modèle complet.
L'habilitation n'est pas configurable par utilisateur. Elle suit le rôle d'organisation. Accorder à quelqu'un l'accès à des documents de niveau d'habilitation supérieur nécessite de le promouvoir, et non de lui attribuer un indicateur d'habilitation.
Pourquoi cette structure
- Une seule hiérarchie, utilisée partout. Les vérifications dans l'interface, sur le serveur, dans les filtres du journal d'audit et dans les politiques Rego consultent toutes le même modèle. Pas de divergence entre la surface et le backend.
- Passage à l'échelle via les équipes. Les droits d'appartenance directe ne passent pas à l'échelle avec des milliers d'utilisateurs ; les droits d'équipe le font, et ils survivent aux changements du cycle de vie des utilisateurs pilotés par l'IdP.
- Adapté à l'audit. Chaque droit a une source enregistrée — directe, par équipe ou au niveau de l'organisation — afin que le journal d'audit puisse répondre à « comment cet utilisateur a-t-il obtenu cet accès » sans ambiguïté.
Voir aussi
- Autorisation — le point de décision de politique qui utilise ce modèle.
- Identité & Provisionnement — correspondance groupe SCIM → équipe.
- Habilitation de la base de connaissances — l'axe d'habilitation au niveau des documents.
- Journal d'audit — chaque attribution et révocation de permission est journalisée.