Identity and Access Management

Zur Anbindung der Plattform empfiehlt sich im Sinne einer konsequenten Open-Source-Strategie ein Keycloak zur Verwaltung der Benutzer, Gruppen und ihren Rollen. Die LLM-Gateway setzt zusätzlich auf eine Service-Account Struktur für die Authentifizierung von Anwendungen, während Keycloak die Benutzerauthentifizierung für RAG-Anwendungen, Chat-Interfaces und andere interaktive Dienste übernimmt.

Keycloak Integration

Warum Keycloak?

Open-Source und Community-getrieben: Keine Vendor-Lock-ins, vollständige Kontrolle über die Identitätsverwaltung
Enterprise-ready: Bewährte Sicherheitsstandards (OAuth 2.0, OIDC, SAML)
Flexible Integration: REST APIs und Standard-Protokolle für einfache Anbindung
Skalierbarkeit: Unterstützt sowohl kleine Teams als auch Enterprise-Deployments
Rollenbasierte Zugriffskontrolle: Granulare Berechtigungen für verschiedene Anwendungen

Beispielhafte Claims

Standard Claims (OIDC):

{
  "sub": "benutzer123",
  "email": "max.mustermann@organisation.de",
  "preferred_username": "mmustermann",
  "given_name": "Max",
  "family_name": "Mustermann",
  ...
}

Organisatorische Claims:

{
  "team_id": "BW-001",
  "org_id": "bw-verwaltung",
  "cost_center": "IT-001",
  "department": "Digitalisierung",
  "roles": ["llm_user", "rag_admin", "chat_moderator"],
  ...
}

Anwendungsspezifische Claims:

{
  "rag_access": ["legal_docs", "hr_knowledge"],
  "chat_channels": ["general", "it_support"],
  "model_access": ["mistral-medium", "llama-3"],
  "budget_limit": 500.0
}

Service Account-basierte Authentifizierung

Neben der Benutzer-Authentifizierung über Keycloak wird für Anwendungen eine Service-Account-Struktur eingesetzt, die eine klare Trennung zwischen technischen und personengebundenen Identitäten ermöglicht.

Primäre Ebene (erforderlich):

Die primäre Ebene dient zur eindeutigen Authentifizierung von Service-zu-Service-Verbindungen und stellt sicher, dass nur autorisierte Anwendungen direkten Zugriff auf das LLM-Gateway erhalten.

Service Account API-Schlüssel: Bearer Token im Format sa-xxxxxxxx
Beispiel-Konfiguration:

{
"service_account_id": "chatbot-prod",
"max_budget": 1000.0,
"models": ["Llama-3.3-70b", "Mistral-Medium"],
"tpm_limit": 50000,
"rpm_limit": 500
}

Verwendung: HTTP Header Authorization: Bearer sa-xxxxxxxxx

Sekundäre Ebene (optional):

Die sekundäre Ebene liefert weitere organisatiorische Claims (wie z.B. user_id, team_id), die vorrangig für das Monitoring benutzt werden.

Kiva JWT: Standard JWT mit organisatorischen Claims
Beispiel-Claims:

{
"sub": "benutzer123",
"team_id": "BW-001",
"org_id": "bw-verwaltung",
"cost_center": "IT-001"
}

Verwendung: HTTP Header X-Kiva-JWT: eyJ0eXAiOiJKV1QiLCJhbGciOi...

Vorteile gegenüber benutzerbasierter Verwaltung

Vereinfachte Verwaltung: Keine individuelle Benutzer-Verwaltung nötig
Bessere Skalierung: Weniger Authentifizierungsentitäten
Flexible Kostenzuordnung: Service Account + optionale organisatorische Zuordnung
Klare Audit-Trails: Zweckgebundene Zugriffe sind leichter nachverfolgbar

Authentifizierungsablauf

Authentication Flow

Anwendungsspezifisches Access Management

Das IAM-System verwaltet Zugriffe für verschiedene Anwendungstypen mit unterschiedlichen Sicherheitsanforderungen.

Integration zwischen Service Accounts und Benutzern

Hybrid-Authentifizierung:

Service Account authentifiziert die Anwendung gegen LLM-Gateway
Keycloak JWT identifiziert den Endbenutzer und dessen Berechtigungen
Kombinierte Autorisierung prüft sowohl Service-Account-Budget als auch Benutzerrechte