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.
Vous cherchez le tableau complet de qui peut utiliser quel produit et de ce que chaque rôle peut faire sur chaque ressource ? Consultez Rôles et permissions — cette page explique comment une décision est résolue ; l'autre en donne le quoi complet.
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 (une fois cette adresse vérifiée) ou promue par un autre super admin 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étenue par utilisateur, sous la forme d'un rang dans le schéma de classification actif de votre organisation. Elle est indépendante du rôle d'organisation : un propriétaire ou un admin ne reçoit aucune habilitation du fait de son rôle, et un membre peut détenir n'importe quel rang qui lui a été accordé.
| Source | Résultat |
|---|---|
| Aucune attribution | Le rang de base du schéma |
| Habilitation de base | Un rang durable défini par membre par un admin de l'organisation, ou provisionné depuis les revendications de votre fournisseur d'identité |
| Dérogation temporaire | Une élévation limitée dans le temps (≤ 90 jours) au-dessus de la base, approuvée par un second admin (quatre yeux) |
Un membre d'espace de travail avec un accès complet à l'espace de travail ne peut toujours pas consulter un document de la base de connaissances classifié au-dessus de son habilitation. Voir Habilitation de la base de connaissances pour le modèle complet.
Promouvoir quelqu'un au rôle d'admin n'élève pas son habilitation, et le rétrograder ne l'abaisse pas. Accordez ou modifiez l'habilitation explicitement ; chaque changement est audité.
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.