Open WebUI absichern: Benutzergruppen, RBAC und Modell-Zugriffssteuerung für den KI-Firmen-Chat

Wer Open WebUI zunächst allein testet, stößt schnell auf eine unbequeme Wahrheit: Ohne weitere Konfiguration hat jeder registrierte Nutzer Zugriff auf alle Modelle, alle Features und – je nach Einstellung – sogar auf Chats anderer Nutzer. Für ein Team-Deployment ist das inakzeptabel. Glücklicherweise steckt in Open WebUI ein produktionsreifes Berechtigungssystem mit drei Rollen, über 40 granularen Feature-Flags, Gruppen-basierter Modell-Freigabe und vollständiger SSO-Integration. Diese Anleitung zeigt, wie du aus einer einfachen lokalen KI-Instanz eine sauber abgesicherte Team-Plattform machst – für Firmen jeder Größe.

Voraussetzungen

1. Laufende Open WebUI Installation via Docker oder Docker Compose (siehe Ollama und Open WebUI mit Docker: eigenes lokales KI-Sprachmodell)
2. Zugang zum Admin-Panel (du bist der erste registrierte Nutzer der Installation)
3. .env-Datei oder environment-Sektion in docker-compose.yml für Umgebungsvariablen
4. WEBUI_SECRET_KEY: langer kryptografischer Zufallswert – generiere ihn einmalig mit openssl rand -hex 32
5. Für SSO: OIDC-Client-Credentials (Client ID + Secret) vom Identity Provider deiner Wahl
6. Für Microsoft SSO: Azure App Registration mit korrekten Redirect-URIs
7. Für Trusted-Header-Auth (Cloudflare, Tailscale): konfigurierter Reverse-Proxy, der die Nutzer-Header setzt – Open-WebUI-Port darf dabei nie direkt erreichbar sein

Schritt 1: Sicheres Basis-Setup – die richtigen Umgebungsvariablen

Bevor der erste Kollege die URL erhält, müssen die kritischen Sicherheitsvariablen gesetzt sein. Der gefährlichste Standardwert ist DEFAULT_USER_ROLE: In manchen älteren Installationen steht er auf user, was neu registrierten Personen sofortigen Zugriff gibt. Setze ihn explizit auf pending.

# docker-compose.yml (Auszug – sicherheitsrelevante Variablen)
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:latest
    environment:
      # Basis-Absicherung
      WEBUI_SECRET_KEY: "dein-langer-zufaelliger-geheimschluessel"
      WEBUI_URL: "https://chat.firma.de"

      # Erster Admin (wird bei Erststart automatisch angelegt)
      WEBUI_ADMIN_EMAIL: "admin@firma.de"
      WEBUI_ADMIN_PASSWORD: "sicheres-admin-passwort"
      WEBUI_ADMIN_NAME: "IT-Admin"

      # Neue Nutzer müssen erst freigegeben werden
      DEFAULT_USER_ROLE: "pending"

      # Registrierung deaktivieren, wenn nur SSO gewünscht
      ENABLE_SIGNUP: "true"

      # Admins können keine Nutzer-Chats lesen (Datenschutz/DSGVO)
      ENABLE_ADMIN_CHAT_ACCESS: "false"

      # Globale Default-Permissions restriktiv setzen
      USER_PERMISSIONS_CHAT_FILE_UPLOAD: "false"
      USER_PERMISSIONS_FEATURES_WEB_SEARCH: "false"
      USER_PERMISSIONS_FEATURES_IMAGE_GENERATION: "false"
      USER_PERMISSIONS_WORKSPACE_MODELS_ACCESS: "false"

Verifizieren: Öffne die Instanz in einem Inkognito-Fenster und registriere einen Test-Account. Der Nutzer sollte nach der Registrierung eine Meldung erhalten, dass sein Account auf Freigabe wartet – und keinerlei Chat-Oberfläche sehen. Im Admin Panel unter Users taucht er mit Status „Pending" auf.

Das Rollen- und Permissions-Modell verstehen

Open WebUI kennt genau drei Systemrollen. Entscheidend ist das additive Modell: Es gibt keine Deny-Regeln. Wer einmal eine Berechtigung durch eine Gruppe erhält, kann sie nicht durch eine andere Gruppe wieder verlieren. Die effektiven Rechte eines Nutzers sind die Vereinigungsmenge aus den globalen Defaults und allen Gruppen-Mitgliedschaften.

Die über 40 Feature-Flags verteilen sich auf fünf Kategorien. Die sicherheitskritischsten auf einen Blick:

Wichtig: workspace.tools.access gibt faktisch Shell-ähnlichen Zugriff auf die Serverumgebung. Dieses Flag gehört ausschließlich in eine dedizierte Entwickler-Gruppe – niemals in die Global Defaults oder eine breite Nutzergruppe.

Schritt 2: Gruppen anlegen und strukturieren

Gruppen dienen in Open WebUI zwei verschiedenen Zwecken, die man sauber trennen sollte: Berechtigungsgruppen aktivieren Feature-Flags für ihre Mitglieder, Freigabegruppen teilen Ressourcen wie Modelle oder Knowledge Bases mit einem Team. Diese Trennung hält das System übersichtlich und wartbar.

Der Weg im Admin Panel: Admin Panel > Users > Groups > „+ New Group"

Empfohlene Namenskonvention und Konfiguration:

1. [Perms] Web-Search – Sichtbarkeit: „No one" (taucht nicht in Share-Menüs auf), Permissions: features.web_search aktiviert
2. [Perms] Developer – Sichtbarkeit: „No one", Permissions: workspace.tools.access, features.code_interpreter, features.api_keys
3. Team-Vertrieb – Sichtbarkeit: „Members", keine eigenen Permissions, dient als Freigabe-Ziel für Ressourcen
4. Team-Marketing – Sichtbarkeit: „Members", optional features.image_generation

Ein Nutzer kann Mitglied mehrerer Gruppen sein. Ein Vertriebsmitarbeiter, der auch Web-Suche benötigt, kommt in beide Gruppen – „Team-Vertrieb" und „[Perms] Web-Search". Seine effektiven Rechte sind die Summe beider.

Verifizieren: Im Admin Panel unter Users beim entsprechenden Nutzer auf das Augensymbol (Preview Access) klicken. Die Ansicht zeigt alle Modelle, Knowledge Bases und Tools, auf die dieser Nutzer aktuell Zugriff hat – aggregiert über alle Gruppen und Direkt-Freigaben.

Schritt 3: Modell-Zugriffssteuerung (ACL) einrichten

Jede Ressource in Open WebUI – Modelle, Knowledge Bases, Tools, Skills – hat einen individuellen Visibility-Status. Der Standardwert ist oft „Public", was für den Firmen-Einsatz in der Regel zu offen ist.

So schränkst du ein Modell auf ein bestimmtes Team ein:

1. Workspace > Models > Modell auswählen > Bearbeiten
2. „Visibility" auf Restricted setzen
3. Unter „Access Control" die Gruppe (z. B. „Team-Vertrieb") mit Read-Berechtigung hinzufügen
4. Speichern

Das Modell erscheint im Modell-Selektor danach ausschließlich für Mitglieder dieser Gruppe. Das Marketing-Team sieht es schlicht nicht.

Für den Wildcard-Zugriff (alle Nutzer) steht das Symbol „*" – das entspricht einer öffentlichen Freigabe innerhalb der Instanz. Die drei Stufen im Überblick:

1. Private: Nur der Ersteller und Admins sehen die Ressource
2. Restricted: Explizite Freigabe per Gruppe oder Einzelnutzer mit Read oder Write
3. Public: Alle angemeldeten Nutzer haben Zugriff

Verifizieren: Mit einem Test-Account, der nicht in der freigegebenen Gruppe ist, einloggen und prüfen, ob das Modell im Selektor erscheint. Alternativ per API mit Admin-Token:

# Nutzer-Zugriff prüfen (Admin-Token erforderlich)
curl -H "Authorization: Bearer <ADMIN_TOKEN>" \
     https://chat.firma.de/api/v1/users/<USER_ID>/preview

# Gruppen-Zugriff prüfen
curl -H "Authorization: Bearer <ADMIN_TOKEN>" \
     https://chat.firma.de/api/v1/groups/id/<GROUP_ID>/preview

Schritt 4: SSO-Integration – Microsoft Entra ID (Azure AD)

Für Firmen mit Microsoft 365 ist die Entra-ID-Integration der empfohlene Weg. Nutzer werden automatisch bereitgestellt, und Gruppen sowie Rollen lassen sich bei jedem Login aus den Azure-Gruppen synchronisieren. Wird ein Mitarbeiter in Azure aus einer Gruppe entfernt, verliert er beim nächsten Login auch in Open WebUI die Gruppenzugehörigkeit.

Voraussetzung: Azure App Registration mit Redirect-URI https://chat.firma.de/oauth/microsoft/callback und den Berechtigungen openid, email, profile.

# .env oder docker-compose environment
ENABLE_OAUTH_SIGNUP=true
ENABLE_PASSWORD_AUTH=false          # Nur SSO – kein lokales Login
ENABLE_PASSWORD_CHANGE_FORM=false

# Microsoft/Entra-spezifisch
MICROSOFT_CLIENT_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
MICROSOFT_CLIENT_SECRET=dein-client-secret
MICROSOFT_CLIENT_TENANT_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
OPENID_PROVIDER_URL=https://login.microsoftonline.com/<TENANT_ID>/v2.0/.well-known/openid-configuration
MICROSOFT_REDIRECT_URI=https://chat.firma.de/oauth/microsoft/callback
MICROSOFT_OAUTH_SCOPE=openid email profile offline_access

# Rollen aus Azure-AD-Gruppen synchronisieren
ENABLE_OAUTH_ROLE_MANAGEMENT=true
OAUTH_ROLES_CLAIM=roles
OAUTH_ALLOWED_ROLES=OpenWebUI-User,OpenWebUI-Admin
OAUTH_ADMIN_ROLES=OpenWebUI-Admin

# Gruppen automatisch synchronisieren
ENABLE_OAUTH_GROUP_MANAGEMENT=true
OAUTH_GROUP_CLAIM=groups
ENABLE_OAUTH_GROUP_CREATION=true

Wer Keycloak oder Authentik einsetzt, nutzt stattdessen die generische OIDC-Konfiguration:

# Generic OIDC (Keycloak, Authentik)
ENABLE_OAUTH_SIGNUP=true
OAUTH_CLIENT_ID=open-webui-client
OAUTH_CLIENT_SECRET=dein-client-secret
OPENID_PROVIDER_URL=https://auth.firma.de/realms/firma/.well-known/openid-configuration
OPENID_REDIRECT_URI=https://chat.firma.de/oauth/oidc/callback
OAUTH_PROVIDER_NAME=Firmen-SSO
OAUTH_SCOPES=openid email profile groups roles

ENABLE_OAUTH_GROUP_MANAGEMENT=true
OAUTH_GROUP_CLAIM=groups
ENABLE_OAUTH_GROUP_CREATION=true

ENABLE_OAUTH_ROLE_MANAGEMENT=true
OAUTH_ROLES_CLAIM=roles
OAUTH_ADMIN_ROLES=admin
OAUTH_ALLOWED_ROLES=user,admin

Verifizieren: Nach dem Neustart des Containers sollte auf der Login-Seite ein Button mit dem konfigurierten Provider-Namen erscheinen. Teste den Login mit einem Nicht-Admin-Account: Er sollte im Status „Pending" landen (da DEFAULT_USER_ROLE=pending) und erst nach Admin-Freigabe Zugriff erhalten – außer er ist in einer der OAUTH_ALLOWED_ROLES-Gruppen im IdP.

Schritt 5: Trusted-Header-Authentifizierung (Cloudflare Tunnel)

Für Installationen hinter Cloudflare Tunnel oder Tailscale Serve lässt sich die Authentifizierung komplett an den Proxy delegieren. Open WebUI liest den Nutzer einfach aus einem HTTP-Header.

# Cloudflare Tunnel + Cloudflare Access
# ACHTUNG: Open-WebUI-Port MUSS hinter dem Tunnel bleiben!
WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Cf-Access-Authenticated-User-Email
ENABLE_SIGNUP=true
DEFAULT_USER_ROLE=pending

Das ist der gefährlichste Konfigurationspfad: Wenn der Open-WebUI-Port direkt im Netz erreichbar ist, kann jeder beliebige Header fälschen und sich als Admin ausgeben. In docker-compose.yml darf das Port-Mapping für Open WebUI in diesem Fall kein öffentlich erreichbares Interface binden – nur 127.0.0.1:3000:8080 oder gar kein Host-Port-Mapping wenn der Tunnel direkt auf den Container-Port geht.

Troubleshooting / Typische Fehler

Neuer Nutzer landet sofort als „User" statt „Pending"

Ältere Installationen oder manche Docker-Images können DEFAULT_USER_ROLE auf user vorbelegt haben. Explizit in der Compose-Datei setzen und Container neu starten. Den aktuellen Wert siehst du im Admin Panel unter Settings > General.

SSO-Login schlägt fehl – „Invalid redirect_uri"

Die Redirect-URI im IdP (z. B. Azure App Registration) muss exakt mit MICROSOFT_REDIRECT_URI bzw. OPENID_REDIRECT_URI übereinstimmen – inklusive Protokoll, Subdomain und Pfad. Trailing Slashes können den Fehler verursachen.

Gruppen aus IdP werden nicht synchronisiert

Prüfe, ob der groups-Claim tatsächlich im JWT enthalten ist. Bei Entra ID müssen Gruppen explizit in der App Registration unter „Token configuration" als Claim hinzugefügt werden. Mit dem Tool jwt.io lässt sich das Token direkt prüfen.

OIDC Back-Channel Logout funktioniert nicht zuverlässig

Wenn ENABLE_OAUTH_BACKCHANNEL_LOGOUT=true gesetzt ist, ohne Redis bereitzustellen, kann JWT-Widerruf scheitern. Redis ist in diesem Fall keine optionale Ergänzung, sondern Voraussetzung für zuverlässiges Session-Beenden.

Admin sieht Workspace-Items aller Nutzer

BYPASS_ADMIN_ACCESS_CONTROL=true ist der Standard – Admins sehen alle Workspace-Items in Listen. Für strikte Datentrennung explizit auf false setzen. Beachte: Dann sehen auch Admins private Modelle anderer Nutzer nicht mehr in der Übersicht.

Berechtigung lässt sich nicht „wegnehmen"

Das additive Modell hat keine Deny-Regeln. Eine Berechtigung kann nur durch Entfernen des Nutzers aus der entsprechenden Gruppe oder durch Ändern der Global Defaults entzogen werden. Wer also versehentlich workspace.tools.access in den Global Defaults aktiviert hat, muss es dort wieder deaktivieren – das Entfernen aus einer Gruppe reicht nicht, wenn es noch im Default aktiv ist.

Häufige Fragen

Wie verhindere ich, dass neue Kollegen sofort nach der Registrierung die KI nutzen können?

DEFAULT_USER_ROLE=pending setzen. Neue Nutzer landen dann im Status „Pending" ohne jeglichen Zugriff. Der Admin sieht sie im Admin Panel > Users und stuft sie einzeln auf „user" hoch. Alternativ ENABLE_SIGNUP=false setzen und Nutzer manuell anlegen oder per SCIM 2.0 automatisch provisionieren.

Kann ich verhindern, dass das Marketing-Team das interne Vertriebs-Sprachmodell sieht?

Ja. Modell bearbeiten, Visibility auf „Restricted" setzen und ausschließlich die Gruppe „Team-Vertrieb" mit „Read" hinzufügen. Das Modell erscheint im Modell-Selektor dann nur für Mitglieder dieser Gruppe – für alle anderen ist es unsichtbar.

Was ist der Unterschied zwischen einer Permissions-Gruppe und einer Freigabegruppe?

Eine Permissions-Gruppe wie „[Perms] Web-Search" hat Feature-Flags aktiviert und Sichtbarkeit „No one" – sie taucht nicht in Share-Menüs auf und dient ausschließlich der Rechtevergabe. Eine Freigabegruppe wie „Team-Vertrieb" hat keine eigenen Permissions, aber Sichtbarkeit „Members", damit Ressourcen gezielt mit dem Team geteilt werden können.

Kann ich das lokale Passwort-Login abschalten und nur SSO erlauben?

ENABLE_PASSWORD_AUTH=false deaktiviert lokale Passwort-Authentifizierung vollständig. Zusätzlich ENABLE_PASSWORD_CHANGE_FORM=false setzen. Wichtig: Sicherstellen, dass ein funktionierender SSO-Provider konfiguriert und getestet ist, bevor diese Einstellung aktiv wird – sonst ist der Zugang für alle Nutzer versperrt.

Unterstützt Open WebUI mehrere SSO-Provider gleichzeitig?

Offiziell nein: Gleichzeitig ist nur ein OIDC-Provider via OPENID_PROVIDER_URL konfigurierbar. Wer Microsoft und Google gleichzeitig anbieten möchte, benötigt den Community-Workaround „Dual OAuth" – in der offiziellen Dokumentation ist das aktuell nicht nativ unterstützt.

Wie überprüfe ich, welche Modelle ein bestimmter Nutzer sieht?

Im Admin Panel unter Users den Nutzer suchen und auf das Augensymbol (Preview Access) klicken. Die Ansicht aggregiert alle Modelle, Knowledge Bases und Tools über alle Gruppen und Direkt-Freigaben. Alternativ per API: GET /api/v1/users/{user_id}/preview mit Admin-Bearer-Token.

Fazit

Open WebUI ist für den Firmeneinsatz deutlich besser gerüstet, als sein schlichtes Interface vermuten lässt. Das additive Permissions-Modell erfordert ein Umdenken – wer aus klassischen Systemen mit Deny-Regeln kommt, muss die Logik verinnerlichen: Restriktiv global, großzügig pro Gruppe. Die Kombination aus DEFAULT_USER_ROLE=pending, sauber getrennten Permissions- und Freigabegruppen sowie Modell-ACLs deckt die meisten KMU-Szenarien ohne externe Abhängigkeiten ab. SSO-Integration mit Gruppen-Sync aus dem Identity Provider macht das Ganze wartbar: Einmal in Azure AD oder Keycloak konfiguriert, läuft die Berechtigungsverwaltung weitgehend automatisch. Das kritische Flag workspace.tools.access verdient besondere Aufmerksamkeit – es gibt Shell-Zugriff und gehört nur in die Hände von Entwicklern und Admins.

Weiterführende Anleitungen und Quellen

1. Ollama und Open WebUI mit Docker: eigenes lokales KI-Sprachmodell ohne Cloud betreiben
2. Open WebUI erweitern: Tools, Functions und Pipelines selbst bauen und einbinden
3. Single Sign-On für den Self-Hosted-Stack: Authentik vs. Authelia mit Traefik Forward-Auth
4. Langfuse selbst hosten: LLM-Observability und Audit-Logging für KI-Anwendungen
5. Quellen: Open WebUI Doku: RBAC, Permissions-Flags, SSO/OIDC-Konfiguration, Umgebungsvariablen-Referenz

Passende Anleitungen auf S-EDV

1. GPT-5.5-Cyber: OpenAI startet Sicherheitsmodell als Konkurrenz zu Anthropic Myth
2. PCI DSS 4.0.1: Checkout-Skripte als Sicherheitsrisiko - was Admins jetzt prüfen
3. Anthropic veröffentlicht Claude Fable 5 und Mythos 5: Frontier-Modell mit Sicher