Confiance · Administration

Utilisateurs, rôles et autorisations

La bonne personne doit voir la bonne fonction et l’API doit appliquer la même décision. Galaris sépare utilisateurs, rôles, privilèges et capacités des agents.

Une chaîne d’autorité lisible

Utilisateur → affectation → rôle actif → privilèges → navigation et API

Un utilisateur peut recevoir plusieurs affectations et choisir le rôle actif autorisé pour sa session. Chaque rôle rassemble des privilèges. La navigation se simplifie en conséquence, mais la protection réelle reste appliquée côté API.

Les affectations de rôles — Les comptes et leurs rôles actifs dans l’instance de développement. Contenus de démonstration substitués aux données privées ; états historiques conservés.
Les affectations de rôles — Les comptes et leurs rôles actifs dans l’instance de développement. Contenus de démonstration substitués aux données privées ; états historiques conservés.C41

Quatre niveaux différents

Utilisateur

Une identité de connexion

Compte, profil, langue, thème, authentification et tokens personnels.

Rôle

Une responsabilité organisée

Un ensemble nommé de privilèges adapté à une fonction.

Privilège

Une action applicative

Voir, modifier, lancer, administrer ou purger une famille de ressources.

Agent

Un périmètre d’exécution

Ses outils et connexions restent filtrés en plus des droits humains.

Profil et sécurité de session

Chaque personne peut gérer son identité, sa langue, son thème et son affectation active. Les sessions persistantes utilisent un renouvellement rotatif. Un second facteur TOTP et des codes de secours peuvent être activés ; un changement de mot de passe ou une déconnexion explicite révoque les sessions concernées.

Prouver le refus

Une démonstration sérieuse ne montre pas seulement une case décochée. Elle utilise deux rôles fictifs : la fonction disparaît pour le premier et la requête directe est refusée par l’API. Le second peut accomplir l’action et la trace reste attribuée.

Comprendre les tokens et les API

Protéger les comptes et leurs sessions

Le second facteur TOTP dispose d’un parcours de préparation, confirmation et désactivation, avec codes de secours à usage unique. Les sessions utilisent des jetons rotatifs ; les tentatives répétées de connexion sont limitées. La gestion des comptes protège le dernier accès administrateur.

Les tokens personnels d’intégration sont distincts des tokens MCP d’un agent. Nommez-les, activez-les ou révoquez-les selon leur usage.

Comprendre les équipes sans élargir les accès

Une équipe peut contenir des humains et des agents. Un membre peut appartenir à plusieurs équipes, sans rendre les autorisations transitives. Partager un document avec une équipe suit ses membres actuels ; cela ne donne pas accès aux conversations privées de chacun.

Documents et partage · API et tokens