Connecting Open WebUI to Nextcloud: RAG with real permissions

A local ChatGPT on your Nextcloud data - with real permissions instead of prompt promises? WZ-IT builds sovereign RAG systems where every query sees only the permitted sources - on your own infrastructure, GDPR-compliant from one team. See custom RAG solutions

A local language model on your own Nextcloud documents is quickly set up: Open WebUI as the interface, a few files in a knowledge base, done. For a prototype that is enough. For production, however, it creates a silent data leak - because the permissions from Nextcloud do not travel with the data automatically. This article shows the architecture of a dependable system: from identity through carrying over the Nextcloud ACLs to the filter in the vector database. As of July 2026.

Table of contents

• The language model is not a bouncer
• The target architecture: ACLs before the vector search
• Shared identity and its secure handover
• Carrying over Nextcloud permissions
• The ACL filter in the vector database
• From proof of concept to production

The language model is not a bouncer

The obvious but wrong path: load all documents into a shared knowledge base and tell the model via a system prompt to show personnel files only to HR. That is not a security boundary. A language model is not an access check - it can be talked into things, and a single unlucky retrieval hit is enough for a passage from a confidential document to land in the answer.

The core of the problem: Open WebUI does not automatically carry over the Nextcloud ACL when a file is uploaded. The personnel file that is visible in Nextcloud only to HR becomes findable in the shared knowledge base for anyone with access to that knowledge base. The solution is a principle from classic enterprise applications: rights are enforced in the backend, not in the presentation layer. Applied to RAG that means - the model receives only passages already authorized for the requesting user.

The target architecture: ACLs before the vector search

Between the interface and the language model sits a dedicated retrieval service that carries the security logic. The flow of a request:

1. The user asks a question in Open WebUI; their identity is handed over securely.
2. The retrieval service resolves identity and groups into security principals.
3. From the principals a mandatory filter for the vector search is built.
4. The vector database returns only hits the filter permits.
5. Only these authorized passages go to the LLM as context.

The language model thus never sees a chunk the user may not see. What is forbidden is not "forbidden" via a prompt but does not reach the model at all.

Shared identity and its secure handover

The foundation is a shared identity via a central identity provider (OIDC): Open WebUI, Nextcloud and the RAG service know the same user through a stable ID - the immutable OIDC sub, not the changeable email.

In the handover from Open WebUI to the retrieval service lies a trap. By default Open WebUI forwards - if enabled - unsigned plaintext headers (X-OpenWebUI-User-Id, -Email, -Name, -Role) that are forgeable on the network path. A signed JWT is only produced if a secret is additionally set via FORWARD_USER_INFO_HEADER_JWT_SECRET; then an HS256-signed token comes in the header X-OpenWebUI-User-Jwt. HS256 is a shared secret, not a public key - the RAG endpoint must therefore be reachable internally only, never directly from the browser.

Important: headers and JWT contain no groups. The RAG service must resolve the groups server-side from the identity provider or via LDAP - access rights must never be derived from client-supplied data.

Carrying over Nextcloud permissions

During indexing a connector computes the effective ACL per document: owner, direct user shares, inherited folder shares and internal group shares. Nextcloud delivers these shares via the OCS Share API; changes to files and shares can be fetched as a feed so the index stays current.

The computed ACL is stored as a list of security principals in the payload of each chunk - directly on the text passages that will later be searched. A deliberate decision concerns public link and federated shares: they should not automatically mean that every AI user gets access. For internal RAG you carry over, by default, only owner, direct user shares and internal group shares.

The ACL filter in the vector database

The decisive technical point: the ACL filter runs together with the similarity search, not after it. Post-filtering - first find the best hits, then remove forbidden ones - is error-prone and weakens tenant separation. A vector database such as Qdrant applies the payload filter directly during the search, so that forbidden chunks do not even enter the result set.

For tenant and rights separation a payload filter over the stored principals is preferable to a separate collection per user. And the direction of failure must be right: on revocation or doubt the rule is fail-closed - no access when in doubt, not the other way round. A revoked right must land in the index promptly, otherwise a document stays visible that must no longer be.

From proof of concept to production

The pragmatic path starts small. For a shared knowledge folder released to all AI users, the built-in knowledge base of Open WebUI is enough - a good proof of concept to show value and answer quality. For mapping individual user and group rights this approach does not hold: the built-in knowledge base does not carry over the Nextcloud ACL on upload.

The step into production is therefore the dedicated retrieval service that Open WebUI calls via an OpenAPI tool or a pipeline - with secure identity, carried-over ACLs and the filter in the vector database. How RAG works in principle is explained in What is RAG?; where the components sit in the bigger picture is shown by The open-source LLM stack.