L’autorisation Admin en 2.0.2 utilise un canonical permission path + action code. Le chemin canonique est un identifiant stable de ressource d’autorisation ; ce n’est ni une route de l’Admin UI ni un chemin de montage HTTP. Par exemple, /runtime/db-management et /auth/role restent les mêmes identifiants d’autorisation même si la navigation ou les URL des contrôleurs changent.
Les mêmes identifiants canoniques servent deux modes d’autorisation d’administration mutuellement exclusifs. Avec l’identité intégrée, les membres et rôles HsSqlAgent résolvent les modèles permission/action. Avec AddHsSqlAgentHostAuthorization(), HsSqlAgent transmet les clés de permission canoniques demandées via HsSqlAgentPermissionResource.Permissions et l’application hôte les mappe vers sa propre politique. Sauf mention contraire, les sections sur les rôles et modèles ci-dessous décrivent le mode d’identité intégré.
Exemples du runtime
| Opération protégée | Paire requise |
|---|---|
| voir Database Management | /runtime/db-management → view |
| créer une entrée Database Management | /runtime/db-management → create |
| modifier les métadonnées sémantiques | /runtime/db-management/semantic → edit |
| émettre/gérer les clés MCP | /runtime/mcp-keys avec l’action correspondante |
| voir les utilisateurs | /auth/user → view |
| modifier les rôles | /auth/role → edit |
| voir l’audit | /runtime/audit → view |
| exporter l’audit | /runtime/audit → export |
| modifier la politique de sécurité | /runtime/security → edit |
| relancer une livraison sortante | /runtime/operability → edit |
En mode d’identité intégré, l’authentification seule n’est donc pas suffisante : la paire chemin/action requise doit aussi être résolue via les rôles du membre. En mode d’autorisation hôte, le même besoin de permission est délégué à la politique de l’application hôte.
Les modèles permission-action font autorité
L’API Role expose un inventaire permission-action-templates. Chaque modèle contient :
- un identifiant, un nom et un chemin de permission ;
- un identifiant, un code et un nom d’action.
Un payload de rôle soumet les sélections sous forme de paires { PermissionId, ActionId }. Le service de rôles normalise les doublons et ne stocke que les paires existantes dans l’inventaire.
Le rôle est l’unité d’attribution
Les membres reçoivent des rôles, et les rôles contiennent des sélections permission/action. Cela sépare le cycle de vie des utilisateurs de la politique d’accès réutilisable :
Member
└─ Role(s)
└─ Permission path + ActionUn membre peut avoir plusieurs rôles. Son accès Admin effectif correspond à la surface cumulée de ces rôles.
Les changements d’autorisation invalident l’état obsolète
La modification d’un rôle est sensible pour la sécurité. Lorsque ses permissions changent, le service trouve les membres concernés, incrémente leur version de sécurité et effectue la mutation via la barrière de cache d’état runtime d’authentification.
Le but est d’empêcher une session déjà authentifiée de conserver une autorisation périmée après modification du rôle.
Rôle SuperUser protégé
SuperUser est un rôle intégré protégé en 2.0.2. Il ne peut pas être modifié ni supprimé par la gestion normale des rôles. Le rôle bootstrap/de contrôle complet ne peut donc pas être redéfini silencieusement avec un autre ensemble de permissions.
Guides associés
- Membres et rôles — cycle de vie des membres et garde-fous des rôles.
- Gestion des bases de données — exemples de permissions DB et sémantiques.
- Clés MCP — les identifiants MCP forment une frontière d’autorisation distincte des rôles Admin.
- Politiques de sécurité — politiques runtime SQL/débit/concurrence gérées par leur propre permission Admin.