Open WebUI an Nextcloud anbinden: RAG mit echten Berechtigungen (ACLs)

Sie wollen ein lokales ChatGPT auf Ihren Nextcloud-Daten - mit echten Rechten statt Prompt-Versprechen? Wir bauen souveräne RAG-Systeme, bei denen jede Anfrage nur die erlaubten Quellen sieht - siehe Custom RAG-Lösungen und KI-Server & lokale KI, oder direkt ein Erstgespräch vereinbaren.

Ein lokales Sprachmodell auf den eigenen Nextcloud-Dokumenten ist schnell aufgesetzt: Open WebUI als Oberfläche, ein paar Dateien in eine Knowledge Base, fertig. Für einen Prototyp reicht das. Für den Produktivbetrieb entsteht damit aber ein stilles Datenleck - denn die Berechtigungen aus Nextcloud wandern nicht automatisch mit.

Die zentrale Regel für ein belastbares System lautet: Die Zugriffskontrolle wird nicht vom Sprachmodell geprüft, sondern vor jeder Vektorsuche technisch erzwungen. Open WebUI ist dabei nur die Oberfläche; die eigentliche Sicherheitslogik liegt in einem eigenen Retrieval-Service. Dieser Beitrag zeigt die Architektur dahinter - von der gemeinsamen Identität über die Übernahme der Nextcloud-ACLs bis zum ACL-Filter in der Vektordatenbank, und den Weg vom POC zum Produktivsystem. Stand Juli 2026.

Inhaltsverzeichnis

• Das Grundproblem: das Sprachmodell ist kein Türsteher
• Die Zielarchitektur: ACLs vor der Vektorsuche
• Eine gemeinsame Identität als Fundament
• Die Identität sicher an den RAG-Service übergeben
• Nextcloud-Berechtigungen in ACLs übernehmen
• Der ACL-Filter bei jeder Vektorsuche
• Rechteentzug und das Fail-closed-Prinzip
• Vom Proof of Concept zum Produktivsystem
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Das Grundproblem: das Sprachmodell ist kein Türsteher

Der naheliegende, aber falsche Weg: alle Dokumente in eine gemeinsame Knowledge Base laden und dem Modell per Systemprompt sagen, es solle Personalakten nur der Personalabteilung zeigen. Das ist keine Sicherheitsgrenze. Ein Sprachmodell ist keine Berechtigungsprüfung - es lässt sich überreden, und ein einziger unglücklicher Retrieval-Treffer genügt, damit ein Textabschnitt aus einem vertraulichen Dokument in der Antwort landet.

Der Kern des Problems bei der einfachen Anbindung: Open WebUI übernimmt beim Hochladen einer Datei nicht automatisch die Nextcloud-ACL. Die Personalakte, die in Nextcloud nur für die Personalabteilung sichtbar ist, wird in der gemeinsamen Wissensbasis für jeden auffindbar, der Zugriff auf diese Knowledge Base hat. Das darf nicht passieren.

Die Lösung ist ein Architekturprinzip aus klassischen Unternehmensanwendungen: Rechte werden im Backend erzwungen, nicht in der Präsentationsschicht. Übertragen auf RAG heißt das - das Modell bekommt ausschließlich Textabschnitte, die für den anfragenden Benutzer bereits autorisiert sind. Was er nicht sehen darf, wird nicht per Prompt "verboten", sondern erreicht das Modell gar nicht erst.

Die Zielarchitektur: ACLs vor der Vektorsuche

Zwischen Oberfläche und Sprachmodell sitzt ein eigener Retrieval-Service, der die Sicherheitslogik trägt:

Benutzer
   │ Anmeldung per OIDC/SSO
   ▼
Open WebUI                     (nur Oberfläche)
   │ geprüfte Benutzeridentität
   ▼
ACL-RAG-Service
   ├── Identität und Gruppen serverseitig ermitteln
   ├── zwingenden ACL-Filter erzeugen
   ├── Vektorsuche mit Filter ausführen
   └── finale Quellen optional erneut autorisieren
   ▼
Qdrant / pgvector              (nur erlaubte Chunks)
   ▼
LLM über vLLM / LiteLLM

Der entscheidende Punkt: Das LLM erhält ausschließlich bereits autorisierte Treffer. Es sieht keine Chunks, die anschließend nur per Prompt zurückgehalten werden.

Eine gemeinsame Identität als Fundament

Damit sich Rechte überhaupt sauber durchziehen lassen, brauchen alle Systeme - Open WebUI, Nextcloud und der RAG-Service - denselben Identity Provider, etwa Keycloak, Microsoft Entra ID oder ein Active Directory.

Ein Benutzer sollte in allen Systemen eine stabile, unveränderliche ID besitzen. Die E-Mail-Adresse ist als dauerhafter Primärschlüssel ungeeignet, weil sie sich ändern kann. Besser ist der OIDC-sub beziehungsweise eine stabile AD-/LDAP-ID. Daraus werden pro Anfrage die Security Principals des Benutzers abgeleitet - seine eigene ID plus alle Gruppen, denen er angehört (etwa group:idp:vertrieb, group:idp:alle-mitarbeiter). Genau gegen diese Principals wird später der Suchfilter gebaut.

Die Identität sicher an den RAG-Service übergeben

Hier lohnt der genaue Blick, weil an dieser Stelle die meisten Fehleinschätzungen passieren. Open WebUI kann Benutzerinformationen an externe OpenAPI- oder MCP-Toolserver weiterreichen - aber nicht automatisch und nicht kryptografisch abgesichert per Default.

Standardmäßig ist die Weitergabe ausgeschaltet. Erst wenn ENABLE_FORWARD_USER_INFO_HEADERS=true gesetzt ist, sendet Open WebUI vier Klartext-Header an den Toolserver: X-OpenWebUI-User-Id, X-OpenWebUI-User-Email, X-OpenWebUI-User-Name und X-OpenWebUI-User-Role. Die Open-WebUI-Dokumentation weist selbst darauf hin, dass dies unsignierte Header sind, die jeder auf dem Netzwerkpfad fälschen könnte (Open WebUI Environment Configuration).

Ein signiertes Token gibt es nur als Opt-in: Wird zusätzlich die Umgebungsvariable FORWARD_USER_INFO_HEADER_JWT_SECRET gesetzt, ersetzt Open WebUI die Klartext-Header durch ein HS256-signiertes JWT im Header X-OpenWebUI-User-Jwt (Standard-Gültigkeit 300 Sekunden). Wichtig: HS256 nutzt ein geteiltes Secret, keinen öffentlichen Schlüssel - der RAG-Service verifiziert mit demselben Secret. Zwei Konsequenzen für die Praxis:

• Der RAG-Endpunkt darf nicht direkt aus dem Browser erreichbar sein. Nur Open WebUI beziehungsweise ein internes API-Gateway ruft ihn auf; er liegt im internen Netz.
• Gruppen sind im Token nicht enthalten. Weder die Klartext-Header noch das JWT tragen die Gruppenzugehörigkeit. Der RAG-Service muss die Gruppen deshalb selbst aus dem OIDC-Token beziehungsweise per LDAP auflösen und kurz cachen. Das ist die korrekte Grenze: Der Benutzer sendet keine ACLs und keine Gruppen mit - der Server ermittelt sie ausschließlich aus der geprüften Identität.

Für die Anbindung selbst unterstützt Open WebUI externe OpenAPI-Toolserver, die zentral durch einen Administrator registriert werden; globale Tools werden vom Open-WebUI-Backend aufgerufen (Open WebUI Tools).

Nextcloud-Berechtigungen in ACLs übernehmen

Beim Indexieren muss der Connector für jedes Dokument die effektive ACL bestimmen: Wem gehört es, mit wem ist es direkt geteilt, liegt es in einem geteilten übergeordneten Ordner, greifen zusätzliche File-Access-Control-Regeln? Nextcloud stellt diese Freigaben über die OCS Share API bereit. Für einen Pfad lassen sich die Shares abfragen; mit dem Parameter reshares erhält man nicht nur die eigenen, sondern alle Freigaben einer Datei, mit subfiles alle Freigaben innerhalb eines Ordners (Nextcloud OCS Share API).

Für internes RAG übernimmt man standardmäßig nur Eigentümer, direkte Benutzerfreigaben, interne Gruppenfreigaben und explizit freigegebene Teamordner. Öffentliche Linkfreigaben sollten nicht automatisch bedeuten, dass jeder KI-Benutzer Zugriff bekommt. Die berechnete effektive ACL wird beim Indexieren materialisiert und als Liste von Principals im Payload jedes Chunks gespeichert:

{
  "tenant_id": "kunde-a",
  "document_id": "nextcloud:file:597996",
  "chunk_id": "nextcloud:file:597996:chunk:12",
  "allow_principals": ["user:nc:mueller", "group:idp:vertrieb"],
  "visibility": "restricted",
  "deleted": false
}

Für laufende Änderungen bietet Nextcloud seit Version 27 die FullTextSearch Collection API. Sie ist genau für die Indexierung in eine externe Suchmaschine gedacht und liefert neue, geänderte und neu geteilte Dokumente samt Inhalt als Feed. Ein wichtiger Sicherheitshinweis steht dabei wörtlich in der Dokumentation: Das mit der Collection verknüpfte technische Konto erhält über diese API Zugriff auf die Inhalte aller Nextcloud-Benutzer (Nextcloud FullTextSearch Collection API). Der Connector ist damit eine hochprivilegierte Komponente und muss entsprechend abgesichert werden. Ergänzend liefert Nextcloud Dateien über WebDAV für Download und Änderungserkennung.

Der ACL-Filter bei jeder Vektorsuche

Aus den Principals des Benutzers erzeugt der Retrieval-Service einen zwingenden Filter, der zusammen mit der Vektorsuche ausgeführt wird. In Qdrant sieht das konzeptionell so aus:

from qdrant_client.models import FieldCondition, Filter, MatchAny, MatchValue

user_principals = ["user:idp:8db4...", "group:idp:vertrieb", "group:idp:mitarbeiter"]

query_filter = Filter(
    must=[
        FieldCondition(key="tenant_id", match=MatchValue(value="kunde-a")),
        FieldCondition(key="deleted", match=MatchValue(value=False)),
    ],
    should=[
        FieldCondition(key="visibility", match=MatchValue(value="all_authenticated")),
        FieldCondition(key="allow_principals", match=MatchAny(any=user_principals)),
    ],
    must_not=[
        FieldCondition(key="deny_principals", match=MatchAny(any=user_principals)),
    ],
)

Entscheidend ist, was hier nicht passiert: keine ungefilterte Suche nach den Top 100 Dokumenten mit anschließendem Entfernen der verbotenen Treffer. Qdrant integriert die Filterbedingung direkt in die Graph-Traversierung der Ähnlichkeitssuche (filterable HNSW) statt als Nachfilterung (Qdrant Filtering). Damit sieht das Modell verbotene Chunks nicht - anders als bei einer Nachfilterung, die fehleranfällig ist und die Mandantentrennung aufweicht.

Für die Trennung mehrerer Kunden empfiehlt Qdrant ausdrücklich eine Collection mit Payload-Partitionierung (ein tenant_id-Feld) statt einer eigenen Collection pro Nutzer; das Tenant-Feld sollte als Payload-Index angelegt werden (Qdrant Multitenancy). Zwei Regeln sind nicht verhandelbar: Der tenant_id-Filter ist immer verpflichtend, und kein Suchendpunkt akzeptiert frei angegebene Benutzer- oder Gruppen-IDs.

Rechteentzug und das Fail-closed-Prinzip

Ein Produktivsystem darf nicht nur neue Dateien indexieren, sondern muss auch Rechteentzüge schnell umsetzen - eine entfernte Freigabe, ein deaktivierter Benutzer, ein aus einer Gruppe entferntes Mitglied. Bewährt haben sich zwei getrennte Synchronisationspfade: ein Content-Sync (Text und Dateiversion) und ein ACL-Sync (Berechtigungen über Share API und Identity Provider), ergänzt um einen regelmäßigen vollständigen Abgleich nachts. Sicherheitskritische Änderungen invalidieren den Cache sofort.

Bei unklarer oder fehlerhafter ACL gilt fail-closed: Lässt sich die Berechtigung nicht ermitteln, ist das Dokument nicht suchbar - niemals umgekehrt. Für besonders sensible Daten (Personal, Recht, Geschäftsführung) lohnt eine zweite Prüfung: Die Top-Treffer der Vektorsuche werden vor der Übergabe an das Modell noch einmal gegen den aktuellen Stand autorisiert. Das verkleinert das Zeitfenster zwischen einem Entzug in Nextcloud und der nächsten Indexsynchronisation.

Vom Proof of Concept zum Produktivsystem

Nicht jedes Projekt muss sofort die volle Architektur bauen. Sinnvoll sind zwei Stufen:

Proof of Concept - ein gemeinsamer Wissensordner. In Nextcloud einen klar abgegrenzten Ordner anlegen (etwa /Unternehmenswissen-KI/), in den nur Dokumente kommen, die alle vorgesehenen KI-Nutzer sehen dürfen. Ein technischer Read-only-Benutzer erhält nur auf diesen Ordner Zugriff; der Ordner wird per WebDAV oder Nextcloud-Client mit der eingebauten Open-WebUI-Knowledge-Base synchronisiert. Die Formel: eine Nextcloud-Freigabe = eine Knowledge Base = eine definierte Benutzergruppe. Das ist schnell produktiv, aber ausdrücklich nicht für individuelle Benutzerrechte gedacht.

Produktivsystem - eigener ACL-fähiger Retrieval-Service. Sobald individuelle Benutzer- und Gruppenrechte abgebildet werden müssen, führt der Weg über einen eigenen Retrieval-Service (etwa FastAPI): JWT-Prüfung, Principal-Auflösung, ACL-Filter und Quellenprüfung, gespeist von einem Nextcloud-Connector über FullTextSearch Collection API, WebDAV und OCS Share API. PostgreSQL führt Dokumentstatus, ACL-Zuordnung und Audit; Qdrant hält die Embeddings mit ACL-Payload. Open WebUI bindet diesen Service über ein OpenAPI-Tool ein. Das ist auch der Punkt, an dem sich Langfuse für LLM-Observability und ein sauberes Audit auszahlen.

Unser Vorgehen bei WZ-IT

Wir bauen solche Systeme als Custom RAG-Lösung auf souveräner Infrastruktur - vollständig lokal oder in europäischer Cloud, ohne dass Daten an US-KI-Dienste abfließen:

1. Datenklassifizierung zuerst. Bevor Hardware ins Haus kommt, klären wir, welche Daten überhaupt in die KI dürfen, welche Freigabestruktur in Nextcloud besteht und welcher Identity Provider die Principals liefert.
2. Sicherheit im Backend, nicht im Prompt. Der ACL-Filter läuft im Retrieval-Service, zwingend bei jeder Suche, fail-closed. Das Modell sieht nur autorisierte Treffer.
3. Betreiben und pflegen. ACL-Sync, Rechteentzug, Reindexierung und Modell-Updates laufen als Vertrag - inklusive Audit-Log darüber, welche Quelle mit welcher ACL-Version an welche Anfrage ging.

So wird aus "ein Chatbot auf unseren Dateien" ein System, dessen Zugriffsschutz so belastbar ist wie der einer klassischen Fachanwendung - unabhängig davon, wie kooperativ das Modell gerade ist.

Weiterführende Guides

• Open WebUI vs. AnythingLLM - welches Interface für selbstgehostete LLMs zu Ihnen passt.
• Lokale KI für Arztpraxen: §203, DSGVO und der RAG-Weg - dieselbe ACL-Idee im streng vertraulichen Kontext.
• Langfuse self-hosted: LLM-Observability für den EU AI Act - Nachvollziehbarkeit und Logging für produktive KI.
• Custom RAG-Lösungen - unser Ansatz für Retrieval mit Quellen und Rechten.

Bevor die erste Personalakte im falschen Chatfenster landet: Wir konzipieren und betreiben RAG-Systeme, bei denen die Berechtigungen technisch erzwungen werden - nicht dem Sprachmodell überlassen. Jetzt Erstgespräch vereinbaren.

Quellen

• Open WebUI: Environment Variable Configuration (Header-/JWT-Weitergabe)
• Open WebUI: OpenAPI Tool Servers
• Open WebUI: Knowledge & Datei-API
• Nextcloud: OCS Share API
• Nextcloud: OCS FullTextSearch Collection API
• Nextcloud: WebDAV Basic File Operations
• Qdrant: Filtering
• Qdrant: Multitenancy