Sicherheitsarchitektur
Überblick
Die Sicherheitsarchitektur von F13 basiert auf Authentifizierung, Autorisierung und einer kontrollierten Infrastrukturumgebung. Die zentrale Komponente für Identitäts- und Sitzungsmanagement ist die Open-Source-Lösung Keycloak.
Authentifizierung
F13 setzt für die Authentifizierung vollständig auf Keycloak. Der Zugriff auf F13 Core erfolgt über JSON Web Tokens (JWT), die vom Frontend an die REST-API übertragen werden. Nach erfolgreicher Anmeldung stellt Keycloak dem Benutzer bzw. dem Frontend drei zeitlich befristete Tokens bereit:
- ID-Token (enthält grundlegende Metadaten des Benutzers),
- Access-Token (für den Zugriff auf F13 Core),
- Refresh-Token (zur Erneuerung abgelaufener Access-Tokens).
Alle Tokens besitzen eine kurze Gültigkeitsdauer von fünf Minuten und sind stets einer Keycloak-Session zugeordnet, die durch Administratorinnen und Administratoren beendet werden kann. F13 Core überprüft den Access-Token über JWKS, speichert jedoch keine Token- oder Stammdaten und führt keine eigenen Sessions.
Autorisierung
F13-Core fragt nach erfolgreicher Authentifizierung Keycloak nach den Berechtigungen eines Benutzers ab. Die nötigen Berechtigungen sind den Endpunkten statisch zugewiesen.
Technische Details
F13 Core stellt eine User-Managed Access (UMA) Anfrage an Keycloak. Als Resultat stellt Keycloak einen Requesting Party Token (RPT) aus, welcher die Berechtigungen des Benutzers enthält. F13 Core stellt diese UMA-Anfrage nicht bei jedem Request, sondern speichert Berechtigungen intern auf Basis der Session ID.
Keycloak bietet auf der Basis von Resourcen, Policies und Permissions die Möglichkeit, fein-granularen Zugriff auf F13-Anwendungen zu gewähren oder zu verweigern.
Geschützte Ressourcen
F13 definiert folgende geschützte Ressourcen, die jeweils einem Microservice-Endpunkt entsprechen:
| Ressource | Beschreibung |
|---|---|
chat |
Zugriff auf den Chat-Service |
summary |
Zugriff auf den Zusammenfassungs-Service |
rag-file |
Zugriff auf dateibasierte RAG-Recherche |
rag-database |
Zugriff auf datenbankbasierte RAG-Recherche |
transcription |
Berechtigung auf den Transkriptions-Service |
feedback |
Berechtigung zur Abgabe von Feedback |
Policies
Policies definieren, welche Benutzer oder Rollen Zugriff auf Ressourcen erhalten:
| Policy | Beschreibung |
|---|---|
<resource>-policy |
Gewährt Zugriff auf die jeweilige <resource> (siehe Geschütze Ressourcen) für Benutzer mit der Rolle <resource>-access (siehe Rollen) oder admin. Beispiel: chat-policy erlaubt Zugriff auf die Ressource chat für die Rolle chat-access. |
admin-policy |
Gewährt Zugriff ausschließlich für Benutzer mit der Rolle admin |
Rollen
F13 verwendet ein rollenbasiertes Zugriffsmodell (RBAC) mit folgenden Rollen:
| Rolle | Typ | Beschreibung |
|---|---|---|
user |
Composite | Standardrolle für Endbenutzer; enthält alle Zugriffsrollen |
admin |
Realm | Administratorrolle mit erweiterten Rechten |
<resource>-access |
Realm | Einzelberechtigung für Zugriff auf Ressource <resource> (siehe Geschütze Ressourcen) |
Die Composite-Rolle user enthält standardmäßig alle Einzelberechtigungen.
Für eine fein-granulare Steuerung können Benutzern stattdessen einzelne Zugriffsrollen zugewiesen werden.
Beim Login wertet das Frontend die im Token enthaltenen Informationen aus und passt daraufhin Navigation und sichtbare Bereiche dynamisch an. Benutzer sehen nur die Inhalte und Funktionen, für die sie berechtigt sind.
Token-Handling
Das Frontend übernimmt das Caching von Tokens und speichert diese als Cookies. F13 Core führt ausschließlich eine Validierung des Access-Tokens durch und verlässt sich hinsichtlich Sicherheitsmechanismen und Standards vollständig auf Keycloak. Refresh-Tokens werden nur im Frontend genutzt und nicht an Backend-Komponenten weitergereicht.
Identity-Broker und externe Provider
Keycloak kann als Identity Broker betrieben werden, sodass externe Identitätsanbieter (OpenID Connect, SAML und weitere) integriert werden können.
Die notwendigen Claim-Mappings oder Transformationsregeln werden in Keycloak verwaltet.
F13 Core erwartet mindestens die Claims sub und sid.
Sitzungs- und Lebenszyklusmanagement
Die Verwaltung von Sessions erfolgt ausschließlich in Keycloak. Administratorinnen und Administratoren können über Keycloak Session-Limits konfigurieren und kompromittierte Sessions beenden. Nach einer Session-Invalidierung können keine neuen Access-Tokens mehr ausgestellt werden; bestehende Tokens laufen regulär ab.
Kommunikation und Infrastruktur
Die interne Kommunikation zwischen Microservices erfolgt ohne zusätzliche Authentifikation, weshalb der Betrieb in einem vertrauenswürdigen, abgeschotteten Netzwerk erforderlich ist. Verschlüsselte Kommunikation nach außen wird durch einen vorgelagerten Reverse-Proxy sichergestellt. Interne Services reichen Access-Tokens derzeit nicht untereinander weiter; dies kann zukünftig erweitert werden.
Datenschutz und Logging
F13 speichert keine personenbezogenen Daten aus den Tokens. Der ID-Token wird nicht ausgewertet. Im Logging werden personenbezogene Daten vermieden. Zusätzliche Sicherheitsmaßnahmen wie Audit-Logs, Ratenbegrenzung oder Härtung der Infrastruktur liegen im Verantwortungsbereich der Betreiber.