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

Wer Open WebUI zunächst allein testet, stellt vor dem Teambetrieb fest: Ohne weitere Konfiguration hat jeder registrierte Nutzer Zugriff auf alle Modelle, alle Features und – je nach Einstellung – sogar auf Chats anderer Nutzer. Open WebUI bringt dafür ein Berechtigungssystem mit mit drei Rollen, über 40 granularen Feature-Flags, Gruppen-basierter Modell-Freigabe und vollständiger SSO-Integration. Diese Anleitung zeigt, wie Sie eine lokale KI-Instanz in eine abgesicherte Team-Plattform überführen. Grundlage sind die offizielle Dokumentation und die Release Notes zu Open WebUI 0.12 (Stand Oktober 2026), geprüft mit Version 0.12.2.

Voraussetzungen

1. Laufende Open-WebUI-Installation (Version 0.11 oder neuer) via Docker oder Docker Compose (siehe Ollama und Open WebUI mit Docker: eigenes lokales KI-Sprachmodell)
2. Zugang zum Admin-Panel (der erste registrierte Nutzer einer Installation ist automatisch Admin)
3. .env-Datei oder environment-Sektion in docker-compose.yml für Umgebungsvariablen
4. WEBUI_SECRET_KEY: langer kryptografischer Zufallswert – erzeugen Sie ihn einmalig mit openssl rand -hex 32
5. Für SSO: OIDC-Client-Credentials (Client ID + Secret) Ihres Identity Providers
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. Entscheidend ist DEFAULT_USER_ROLE: Aktuelle Versionen verwenden standardmäßig pending, in älteren Installationen und Compose-Vorlagen steht er teils auf user, was neu registrierten Personen sofort Zugriff gibt. Setzen Sie ihn explizit auf pending.

# docker-compose.yml (Auszug – sicherheitsrelevante Variablen)
services:
  open-webui:
    # Feste Version aus den GitHub-Releases statt latest
    image: ghcr.io/open-webui/open-webui:v0.12.2
    environment:
      # Basis-Absicherung
      WEBUI_SECRET_KEY: "<Ausgabe von openssl rand -hex 32>"
      WEBUI_URL: "https://chat.firma.de"

      # Erster Admin (nur bei leerer Datenbank angelegt; danach ist die Registrierung automatisch aus)
      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"

      # Selbstregistrierung: "false", wenn Konten nur per SSO oder durch Admins entstehen
      ENABLE_SIGNUP: "false"

      # 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"

Wenn Sie WEBUI_ADMIN_EMAIL und WEBUI_ADMIN_PASSWORD setzen, schaltet Open WebUI nach dem Anlegen des Admins die Registrierung ab. Soll sich das Team selbst registrieren, aktivieren Sie sie danach unter Admin Panel > Settings > General wieder; neue Konten landen dann als „Pending“.

Verifizieren: Öffnen Sie die Instanz in einem Inkognito-Fenster. Bei deaktivierter Registrierung fehlt der Link „Sign up“. Bei aktivierter Registrierung erhält ein Test-Account nach dem Anlegen den Hinweis, dass die Freigabe aussteht, und sieht keine Chat-Oberfläche; im Admin Panel unter Users erscheint er mit der Rolle „Pending“.

Zwei-Faktor-Anmeldung ab Version 0.12

Seit Open WebUI 0.12 können Admins für alle Konten eine Authenticator-App verlangen: unter Admin Settings > Authentication oder mit ENABLE_MFA: "true". Laut Release Notes richten Nutzer die App bei der nächsten Anmeldung per QR-Code ein und erhalten zehn Einmal-Wiederherstellungscodes. Anmeldungen über OAuth oder einen Trusted Header (Schritt 5) sind ebenfalls an die zweite Stufe gebunden, solange Sie MFA_ALLOW_OAUTH_BYPASS und MFA_ALLOW_TRUSTED_HEADER_BYPASS auf dem Standardwert false lassen; erzwingt Ihr Identity Provider bereits MFA, können Sie die Ausnahme gezielt erlauben. Hat jemand das Gerät verloren, erzeugt open-webui mfa reset im Container ein einmaliges Wiederherstellungs-Token. Ab Werk ist ENABLE_MFA aus.

Verifizieren: GET /api/v1/auths/admin/config mit Admin-Token zeigt ENABLE_MFA. Im Test mit 0.12.2 meldete der Endpunkt nach dem Update "DEFAULT_USER_ROLE":"pending", "ENABLE_SIGNUP":false und "ENABLE_MFA":false.

Update von 0.11 auf 0.12

Der Wechsel braucht keine Handarbeit: Tag in der Compose-Datei ändern, docker compose pull und docker compose up -d. Beim ersten Start führt Open WebUI die Datenbankmigrationen selbst aus, unter anderem für MFA-Status, Gruppenhierarchie und Versionsstände von Skills und Modellen. Sichern Sie vorher das Datenverzeichnis /app/backend/data. Im Test auf 0.12.2 blieben die unter 0.11.4 angelegte Gruppe, die restriktiven Standardrechte und die gesperrte Registrierung (HTTP 403) erhalten, die Anmeldung mit dem bisherigen Admin-Konto funktionierte, ein falsches Passwort wurde abgelehnt. Seit 0.12.2 kann ein Identity Provider über SCIM keine Admin-Konten mehr löschen (Antwort 403).

Das Rollen- und Permissions-Modell verstehen

Open WebUI kennt drei Systemrollen. Entscheidend ist das additive Modell ohne Deny-Regeln: Die effektiven Rechte sind die Vereinigungsmenge aus Global Defaults und allen Gruppen; keine Gruppe kann ein Recht wieder entziehen.

Die Feature-Flags verteilen sich auf mehrere Kategorien. Die sicherheitskritischsten:

Wichtig: Tools führen Python-Code auf dem Server aus. workspace.tools.access gehört deshalb nur in eine Entwicklergruppe, nie in die Global Defaults.

Schritt 2: Gruppen anlegen und strukturieren

Gruppen dienen in Open WebUI zwei verschiedenen Zwecken, die Sie trennen sollten: Berechtigungsgruppen aktivieren Feature-Flags für ihre Mitglieder, Freigabegruppen teilen Ressourcen wie Modelle oder Knowledge Bases mit einem Team. Die offizielle Dokumentation empfiehlt, Freigabegruppen ohne eigene Berechtigungen zu führen: Dann wirkt das Abschalten eines Features in den Global Defaults sofort für alle.

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

Empfohlene Namenskonvention und Konfiguration (Einstellung „Who can share to this group“):

1. [Perms] Web-Search – Who can share: „No one“ (taucht nicht in Share-Menüs auf), Permissions: features.web_search aktiviert
2. [Perms] Developer – Who can share: „No one“, Permissions: workspace.tools.access, features.code_interpreter, features.api_keys
3. Team-Vertrieb – Who can share: „Members“, keine eigenen Permissions, dient als Freigabe-Ziel für Ressourcen
4. Team-Marketing – Who can share: „Members“, keine eigenen Permissions (Bildgenerierung besser über eine eigene Gruppe „[Perms] Image-Gen“)

Ein Vertriebsmitarbeiter mit Web-Suche ist Mitglied in „Team-Vertrieb“ und „[Perms] Web-Search“; seine Rechte sind die Summe beider.

Verifizieren: Im Admin Panel unter Users mit der Maus über die Zeile des Nutzers fahren und 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 (Modell, Knowledge Base, Tool, Skill) hat einen eigenen Visibility-Status. „Public“ ist für den Firmeneinsatz meist zu offen.

So schränken Sie 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 danach nur für Mitglieder dieser Gruppe im Modell-Selektor.

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 bietet sich Entra ID an: Konten entstehen beim ersten Login, Gruppen und Rollen werden bei jedem Login synchronisiert. 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=<CLIENT_SECRET>
MICROSOFT_CLIENT_TENANT_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
# OPENID_PROVIDER_URL wird für Microsoft nicht benötigt
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=<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. Testen Sie den Login mit einem Nicht-Admin-Account: Liefert der roles-Claim nur Rollen außerhalb von OAUTH_ALLOWED_ROLES und OAUTH_ADMIN_ROLES, verweigert Open WebUI die Anmeldung (HTTP 403); fehlt der Claim, gilt DEFAULT_USER_ROLE („Pending“). Mit passender Rolle erhält er die Rolle „User“ und die Gruppen aus dem groups-Claim (sichtbar unter Admin Panel > Users > Groups).

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 dann 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

Ist der Open-WebUI-Port direkt erreichbar, kann jeder den Header fälschen und sich als beliebiger Nutzer anmelden. 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.

Verifizieren: ss -tlnp | grep 3000 auf dem Host zeigt nur 127.0.0.1:3000. Ein Aufruf von http://<Server-IP>:3000 von einem anderen Rechner schlägt fehl, der Aufruf über die Cloudflare-Access-URL meldet Sie ohne Passwortabfrage mit Ihrer E-Mail-Adresse an.

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 sehen Sie im Admin Panel unter Settings > General.

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

Die Redirect-URI im IdP muss exakt mit MICROSOFT_REDIRECT_URI bzw. OPENID_REDIRECT_URI übereinstimmen, inklusive Protokoll, Subdomain, Pfad und abschließendem Schrägstrich.

Gruppen aus IdP werden nicht synchronisiert

Prüfen Sie, 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, löscht Open WebUI zwar die gespeicherten OAuth-Sitzungen, bereits ausgestellte JWTs bleiben aber bis zum Ablauf gültig. Für ein zuverlässiges Beenden der Sitzungen ist Redis Voraussetzung.

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. Beachten Sie: Dann sehen auch Admins private Modelle anderer Nutzer nicht mehr in der Übersicht.

Berechtigung lässt sich nicht „wegnehmen“

Ohne Deny-Regeln entziehen Sie eine Berechtigung nur, indem Sie den Nutzer aus der Gruppe entfernen oder die Global Defaults ändern. Wer 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?

Mit DEFAULT_USER_ROLE=pending (Schritt 1); der Admin stuft neue Konten unter Admin Panel > Users 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. Setzen Sie die Visibility des Modells auf „Restricted“ und geben Sie nur „Team-Vertrieb“ mit „Read“ frei (Schritt 3).

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

Eine Permissions-Gruppe („[Perms] Web-Search“) schaltet Feature-Flags frei und bleibt mit „No one“ aus den Share-Menüs heraus. Eine Freigabegruppe („Team-Vertrieb“) hat keine eigenen Permissions und dient mit „Members“ als Ziel für geteilte Ressourcen.

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. Testen Sie den SSO-Login vorher, sonst sperren Sie alle Nutzer aus.

Unterstützt Open WebUI mehrere SSO-Provider gleichzeitig?

Nur eingeschränkt: Microsoft und Google lassen sich laut Dokumentation nicht gleichzeitig als OIDC-Provider betreiben, und es ist nur ein generischer OIDC-Provider über OPENID_PROVIDER_URL konfigurierbar. Für Microsoft plus Google beschreibt die Dokumentation einen Umweg im Tutorial „Dual OAuth Configuration“.

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

Über Admin Panel > Users und das Augensymbol „Preview Access“ (siehe Schritt 2) oder per API: GET /api/v1/users/{user_id}/preview mit Admin-Token.

Fazit

Open WebUI bringt die nötigen Werkzeuge für den Firmeneinsatz mit. Das additive Permissions-Modell kennt keine Deny-Regeln, daher gilt: restriktiv global, gezielt pro Gruppe. DEFAULT_USER_ROLE=pending, getrennte Permissions- und Freigabegruppen sowie Modell-ACLs decken die meisten KMU-Szenarien ab. Mit SSO und Gruppen-Sync aus Entra ID oder Keycloak pflegen Sie Berechtigungen zentral im Identity Provider. workspace.tools.access gehört nur in eine Entwicklergruppe.

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