Ein lokales ChatGPT auf Ihren Nextcloud-Daten, bei dem jede Person nur sieht, was sie sehen darf?
Im RAG Proof of Value machen wir eine priorisierte Wissensquelle mit Quellenanzeige, Berechtigungsweg und fachlicher Abnahme nutzbar, ab 9.900 € netto. Als lokale Plattform kann der AI Cube dienen; die automatische Nextcloud-Anbindung und die Übernahme der Berechtigungen planen wir passend zum Bestand.
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. Dieser Artikel zeigt die Architektur eines belastbaren Systems: von der Identität über die Übernahme der Nextcloud-ACLs bis zum Filter in der Vektordatenbank. Stand Oktober 2026, Open WebUI v0.12.
Inhaltsverzeichnis
- Das Sprachmodell ist kein Türsteher
- Die Zielarchitektur: ACLs vor der Vektorsuche
- Gemeinsame Identität und ihre sichere Übergabe
- Nextcloud-Berechtigungen übernehmen
- Der ACL-Filter in der Vektordatenbank
- Drei Wege: von oikb bis zum eigenen Retrieval-Service
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 Abschnitt aus einem vertraulichen Dokument in der Antwort landet.
Der Kern des Problems: 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. Die Lösung ist ein Prinzip aus klassischen Unternehmensanwendungen: Rechte werden im Backend erzwungen, nicht in der Präsentationsschicht. Auf RAG übertragen heißt das - das Modell bekommt ausschließlich Abschnitte, die für den anfragenden Benutzer bereits autorisiert sind.
Die Zielarchitektur: ACLs vor der Vektorsuche
Zwischen Oberfläche und Sprachmodell sitzt ein eigener Retrieval-Service, der die Sicherheitslogik trägt. Der Ablauf einer Anfrage:
- Der Benutzer stellt in Open WebUI eine Frage; seine Identität wird sicher weitergereicht.
- Der Retrieval-Service löst Identität und Gruppen zu Security Principals auf.
- Aus den Principals entsteht ein zwingender Filter für die Vektorsuche.
- Die Vektordatenbank liefert nur Treffer, die der Filter erlaubt.
- Erst diese autorisierten Abschnitte gehen als Kontext an das LLM.
Das Sprachmodell sieht damit nie einen Chunk, den der Benutzer nicht sehen darf. Was verboten ist, wird nicht per Prompt „verboten", sondern erreicht das Modell gar nicht erst.
Gemeinsame Identität und ihre sichere Übergabe
Fundament ist eine gemeinsame Identität über einen zentralen Identity Provider (OIDC): Open WebUI, Nextcloud und der RAG-Service kennen denselben Benutzer über eine stabile ID - den unveränderlichen OIDC-sub, nicht die änderbare E-Mail.
Bei der Übergabe von Open WebUI an den Retrieval-Service liegt eine Falle. Ist ENABLE_FORWARD_USER_INFO_HEADERS aktiv, reicht Open WebUI unsignierte Klartext-Header weiter (X-OpenWebUI-User-Id, -Email, -Name, -Role), die auf dem Netzwerkpfad fälschbar sind. Ist zusätzlich FORWARD_USER_INFO_HEADER_JWT_SECRET gesetzt, ersetzt ein HS256-signiertes Token im Header X-OpenWebUI-User-Jwt diese Header; es läuft standardmäßig nach 300 Sekunden ab (Umgebungsvariablen). HS256 ist ein geteiltes Secret, kein öffentlicher Schlüssel. Und das sub in diesem Token ist die interne Open-WebUI-Benutzer-ID, nicht der OIDC-sub: Der Retrieval-Service muss beide Kennungen einander zuordnen.
Der robustere Weg ist das Anmelde-Token aus dem Identity Provider. MCP- und OpenAPI-Toolserver lassen sich in Open WebUI mit der Authentifizierung „OAuth" anbinden; dann erhält der Dienst das Zugriffstoken des Benutzers als Bearer-Token und kann es asymmetrisch gegen den Identity Provider prüfen (MCP in Open WebUI). Seit v0.12.0 wird dabei auch ein erneuertes Token verwendet. Darin steht der echte OIDC-sub, je nach Konfiguration auch Gruppen.
Gruppen gehören nicht in Header, denen man vertrauen muss. Die eingebauten Header und das JWT enthalten keine Gruppen; seit v0.11.0 lassen sich Open-WebUI-Gruppen zwar über die Platzhalter {{USER_GROUPS}} und {{USER_GROUP_IDS}} in eigene Header schreiben, diese sind aber unsigniert. Der RAG-Service löst Gruppen deshalb serverseitig aus dem Identity Provider oder per LDAP auf oder liest sie aus dem verifizierten Token. In jedem Fall gilt: Der Retrieval-Endpunkt ist nur intern erreichbar, nie direkt vom Browser.
Nextcloud-Berechtigungen übernehmen
Beim Indexieren berechnet ein Connector pro Dokument die effektive ACL: Eigentümer, direkte Benutzerfreigaben, geerbte Ordnerfreigaben, Gruppen- und Teams-Freigaben. Diese Freigaben liefert die OCS Share API. Liegen Dokumente in Team Folders (früher Group Folders), kommen deren erweiterte Rechte nicht aus der Share API, sondern über WebDAV mit der Eigenschaft nc:acl-list. Änderungen an Dateien und Freigaben lassen sich über die Activity-API abholen; deren Feed ist allerdings je Benutzer, ein Dienstkonto sieht nur seine eigene Sicht.
Die berechnete ACL wird als Liste von Security Principals im Payload jedes Chunks gespeichert - also direkt an den Textabschnitten, über die später gesucht wird. Eine bewusste Entscheidung betrifft öffentliche Link- und föderierte Freigaben: Sie sollten nicht automatisch bedeuten, dass jeder KI-Nutzer Zugriff bekommt. Für internes RAG übernimmt man standardmäßig nur Eigentümer, direkte Benutzerfreigaben und interne Gruppenfreigaben.
Der ACL-Filter in der Vektordatenbank
Der entscheidende technische Punkt: Der ACL-Filter läuft zusammen mit der Ähnlichkeitssuche, nicht danach. Eine Nachfilterung - erst die besten Treffer suchen, dann verbotene entfernen - ist fehleranfällig und weicht die Mandantentrennung auf. Eine Vektordatenbank wie Qdrant wendet den Payload-Filter direkt während der Suche an, sodass verbotene Chunks gar nicht erst in die Ergebnismenge gelangen.
Für die Mandanten- und Rechtetrennung empfiehlt sich ein Payload-Filter über die gespeicherten Principals statt einer eigenen Collection pro Nutzer. Und die Richtung des Ausfalls muss stimmen: Bei Rechteentzug oder Zweifeln gilt fail-closed - im Zweifel kein Zugriff, nicht andersherum. Ein entzogenes Recht muss zeitnah im Index landen, sonst bleibt ein Dokument sichtbar, das es nicht mehr sein darf.
Drei Wege: von oikb bis zum eigenen Retrieval-Service
Welcher Weg passt, hängt davon ab, wie fein die Rechte sein müssen.
| Weg | Wie Dokumente nach Open WebUI kommen | Rechte | Passt für |
|---|---|---|---|
| Knowledge Base + oikb | Das offizielle Sync-Werkzeug oikb synchronisiert einen Nextcloud-Ordner per WebDAV in eine Knowledge Base, zeitgesteuert und mit Löschungen | Open WebUI vergibt Lese- und Schreibrechte je Knowledge Base an Gruppen; Nextcloud-Rechte je Datei werden nicht übernommen | Wissensbereiche mit klarer Gruppenzuordnung, zum Beispiel je Abteilungsordner eine Knowledge Base |
| Nextcloud-nativ | Context Chat indexiert in Nextcloud; der Context Agent stellt einen MCP-Endpunkt bereit, den Open WebUI als Tool nutzt | Es gilt, was der Benutzer in Nextcloud sieht; Regeln aus files_accesscontrol werden nicht berücksichtigt | Teams, die ohnehin in Nextcloud arbeiten und keine eigene Indexierung betreiben wollen |
| Eigener Retrieval-Service | Eigener Connector mit ACL im Payload, angebunden als MCP- oder OpenAPI-Toolserver mit OAuth-Token | Rechte je Datei, technisch vor der Vektorsuche erzwungen | Produktivsysteme mit vertraulichen Dokumenten und individuellen Freigaben |
Der pragmatische Weg beginnt mit der ersten Variante: Sie zeigt Nutzen und Antwortqualität und braucht keinen eigenen Dienst. Für die Abbildung individueller Benutzer- und Gruppenrechte je Datei trägt sie nicht, auch nicht mit oikb, das mit einem einzigen Dienstkonto synchronisiert. Dann folgt der eigene Retrieval-Service. Den bindet man heute als MCP- oder OpenAPI-Toolserver an; Pipelines führt Open WebUI als Legacy und rät für neue Installationen davon ab.
Eine Neuerung betrifft alle drei Wege: Mit nativem Function Calling fügt Open WebUI angehängte Knowledge Bases nicht mehr automatisch in den Kontext ein, sondern das Modell ruft Werkzeuge wie query_knowledge_files auf (Knowledge). Diese Werkzeuge beachten die Rechte in Open WebUI, nicht die in Nextcloud. Wie RAG grundsätzlich funktioniert, erklärt Was ist RAG?; wo die Komponenten im größeren Bild sitzen, zeigt Der Open-Source-LLM-Stack.
Diesen Weg mit Ihren Nextcloud-Daten gehen?
Im RAG Proof of Value setzen wir den Retrieval-Service mit übernommenen Berechtigungen für eine priorisierte Wissensquelle um und nehmen ihn fachlich ab.
