Berechtigungen | hs-sql-agent

Permission Path Kennzeichnet die geschützte Admin-Ressource, etwa /runtime/db-management oder /auth/user.

Action Kennzeichnet die erlaubte Operation, etwa view, create, edit, delete oder export.

Rollenauswahl Rollen speichern nur Permission/Action-Paare, die im Template-Bestand des Servers existieren.

Die Admin-Autorisierung in 2.0.2 verwendet einen canonical permission path + action code. Der kanonische Pfad ist eine stabile Kennung für eine Autorisierungsressource; er ist weder eine Route der Admin UI noch ein HTTP-Mount-Pfad. /runtime/db-management und /auth/role bleiben beispielsweise dieselben Autorisierungskennungen, auch wenn Navigation oder Controller-URLs anders organisiert werden.

Dieselben kanonischen Kennungen gelten in zwei gegenseitig ausschließenden Autorisierungsmodi. Mit integrierter Identität lösen HsSqlAgent-Mitglieder und -Rollen die Permission/Action-Templates auf. Mit AddHsSqlAgentHostAuthorization() übergibt HsSqlAgent die angeforderten kanonischen Permission Keys über HsSqlAgentPermissionResource.Permissions; die Host-Anwendung ordnet sie ihrem eigenen Policy-Modell zu. Sofern nicht anders angegeben, beschreiben die folgenden Rollen- und Template-Abschnitte den Modus mit integrierter Identität.

Beispiele aus der Laufzeit

Geschützte Operation	Erforderliches Paar
Database Management anzeigen	`/runtime/db-management` → `view`
Database-Management-Eintrag anlegen	`/runtime/db-management` → `create`
semantische Metadaten bearbeiten	`/runtime/db-management/semantic` → `edit`
MCP-Schlüssel ausstellen/verwalten	`/runtime/mcp-keys` mit passender Action
Benutzer anzeigen	`/auth/user` → `view`
Rollen bearbeiten	`/auth/role` → `edit`
Audit anzeigen	`/runtime/audit` → `view`
Audit exportieren	`/runtime/audit` → `export`
Sicherheitsrichtlinie bearbeiten	`/runtime/security` → `edit`
ausgehende Zustellung erneut versuchen	`/runtime/operability` → `edit`

Im Modus mit integrierter Identität reicht Authentifizierung allein daher nicht: Das erforderliche Path/Action-Paar muss zusätzlich über die Rollen des Mitglieds aufgelöst werden. Bei Host-Autorisierung wird dieselbe kanonische Anforderung an die Policy der Host-Anwendung delegiert.

Permission-Action-Templates sind maßgeblich

Die Role API stellt einen Bestand permission-action-templates bereit. Jedes Template enthält:

Permission-ID, Name und Pfad sowie
Action-ID, Code und Name.

Ein Rollen-Payload sendet Auswahlen als { PermissionId, ActionId }-Paare. Der Rollendienst entfernt Duplikate und speichert nur Paare, die im Template-Bestand existieren.

Rollen sind die Zuweisungseinheit

Mitgliedern werden Rollen zugewiesen; Rollen enthalten Permission/Action-Auswahlen. Dadurch bleiben Benutzerlebenszyklus und wiederverwendbare Zugriffspolitik getrennt:

Member
  └─ Role(s)
       └─ Permission path + Action

Ein Mitglied kann mehrere Rollen besitzen. Der effektive Admin-Zugriff ist die kombinierte Berechtigungsfläche dieser Rollen.

Autorisierungsänderungen machen veralteten Zustand ungültig

Rollenänderungen sind sicherheitsrelevant. Wenn sich die Berechtigungen einer Rolle ändern, ermittelt der Dienst betroffene Mitglieder, erhöht deren Security Version und führt die Änderung über die Cache-Barriere für Auth-Laufzeitzustand aus.

So soll verhindert werden, dass bereits authentifizierte Sitzungen mit veralteter Autorisierung weiterlaufen.

Geschützte SuperUser-Rolle

SuperUser ist in 2.0.2 eine integrierte geschützte Rolle. Sie kann über die normale Rollenverwaltung weder bearbeitet noch gelöscht werden. Damit kann die Bootstrap-/Vollzugriffsrolle nicht stillschweigend in eine andere Berechtigungsmenge umdefiniert werden.