Open WebUI : fiche détaillée

L'essentiel

• Trois rôles (admin, user, pending), des groupes, des permissions additives : « True takes precedence over False », aucun « deny ». Bonne pratique documentée : tout désactiver globalement, accorder par groupe ³.
• Les knowledge bases peuvent être « Private » avec des grants read/write par groupe ou utilisateur ; l'admin dispose d'un « Preview Access » qui montre les droits effectifs d'un utilisateur.
• Les défauts du RAG intégré sont inadaptés au français et à la sécurité : Chroma, all-MiniLM-L6-v2 (anglais, 384 dimensions), hybride désactivé, 3 passages, chunks de 1 000 caractères ².
• Quatre CVE de contrôle d'accès documentaire en 2026 (44560, 45402, 54016, 70488), corrigées de 0.9.0 à 0.11.0 : le contrôle est applicatif et a été contourné plusieurs fois. Le RAG de la Box doit fournir sa propre barrière.
• Licence : BSD-3 modifiée depuis 0.6.6, branding intouchable sauf déploiements de 50 utilisateurs finals au plus ; sans contrainte pour un cabinet ¹.

Licence

Texte du LICENSE : interdiction « from altering, removing, obscuring, or replacing any "Open WebUI" branding », sauf (i) « deployments or distributions where the total number of end users (defined as individual natural persons with direct access to the application) does not exceed fifty (50) within any rolling thirty (30) day period », (ii) permission écrite, (iii) licence entreprise. Effectif depuis la v0.6.6 du 19 avril 2025 ; le code jusqu'à 0.6.5 reste BSD-3 pur ; les versions suivantes ne sont plus certifiées OSI ¹. Pour un cabinet de 5 à 10 personnes : aucune contrainte. Pour une Box en marque blanche : licence entreprise à négocier, coût non connu.

Modèle de permissions

Rôles et comptes

• admin : tout ; user : usage ; pending : compte créé mais non validé (rôle par défaut des nouveaux comptes, DEFAULT_USER_ROLE = pending) ².
• Inscription : ENABLE_SIGNUP à désactiver ; création de comptes via SSO avec ENABLE_OAUTH_SIGNUP (défaut False) une fois l'IdP branché.

Catégories de permissions

Workspace (Models, Knowledge, Prompts, Tools, Skills), Sharing (public, vers utilisateurs et groupes), Chat (upload de fichiers, upload web, suppression, édition, chat temporaire, export/import), Features (Web Search, Image Generation, Code Interpreter, Direct Tool Servers, Memories, Automations, Calendar, API Keys), Settings ³.

Règle d'agrégation

« A user's effective permissions are the combination of Global Defaults and all their Group Memberships. True takes precedence over False » et « You cannot use a specific group to "take away" a permission that is granted by another group or by the global defaults » ³. Conséquence : le seul schéma sûr est tout à False dans les défauts globaux, puis des groupes qui accordent. Un groupe « secrétariat » ne peut pas retirer un droit accordé par défaut.

Groupes

Créés à la main ou synchronisés depuis l'IdP : ENABLE_OAUTH_GROUP_MANAGEMENT, claim OAUTH_GROUPS_CLAIM (défaut groups), ENABLE_OAUTH_GROUP_CREATION ; « Users are strictly added/removed from groups to match their OAuth claims » ³. C'est le point d'ancrage avec l'identité : un groupe Entra ID « dossier-A » devient un groupe Open WebUI.

Knowledge privées et grants

Chaque modèle ou knowledge base peut être « Private » avec des grants « Resource, Principal (group or user), Permission (read or write) ». Visibilité d'un groupe : Anyone / Members / No one. L'admin dispose de « Preview Access » qui « resolves every access grant for a specific user or group and lists the result in one place » (API /api/v1/users/…/preview, /api/v1/groups/id/…/preview) ³.

Limite de gouvernance (communauté, discussion #15100 ouverte depuis le 18/06/2025) : tout membre d'un groupe peut partager une ressource qu'il crée avec tout le groupe, sans contrôle fin ³ Communauté.

Variables d'environnement clés

Valeurs par défaut lues dans backend/open_webui/config.py (branche main au 16/09/2026) et la documentation ^{2 4}.

RAG intégré : ce qu'il fait et ses défauts

Fonctions : knowledge bases dans le Workspace, attachement de fichiers ou d'URL par #, recherche web, splitter par caractères ou tokens avec « Markdown header splitting » et « Chunk Min Size Target », hybride « BM25 keyword search plus vector similarity with CrossEncoder reranking », citations, mode agentic (le modèle interroge la knowledge via outils), extraction Tika / Docling / Mistral OCR, bases externes Qdrant / Milvus / pgvector ⁵.

Défauts à corriger avant tout usage en français : Chroma (le Cookbook communautaire juge l'approche multi-utilisateur naïve « not well suited for production ») ⁹, all-MiniLM-L6-v2 (anglais, 384 dimensions), hybride désactivé, reranker absent, 3 passages, chunks de 1 000 caractères ².

Ce qui manque pour la cible : synchronisation depuis SMB/SharePoint avec propagation des ACL, métadonnées de dossier, citations page à page avec lien vers la pièce, évaluation, barrière moteur.

Brancher un RAG externe

Trois voies, à comparer dans l'expérimentation dédiée :

1. Pipelines / Functions : un filtre Open WebUI intercepte la question, appelle le service RAG de la Box avec l'identité de l'utilisateur (issue de la session Open WebUI, elle-même issue du SSO), injecte les passages autorisés et les métadonnées de citation dans le prompt. Avantage : l'utilisateur garde l'interface Open WebUI. Risque : l'identité transmise doit être celle de la session, jamais un champ modifiable.
2. Endpoint OpenAI-compatible : le service RAG de la Box se présente comme un « modèle » ; Open WebUI l'appelle comme un LLM ; le service fait recherche + génération et renvoie la réponse avec citations. Simple, isole complètement le RAG ; l'identité passe par un en-tête ou un jeton transmis par Open WebUI (à vérifier).
3. Outil (tool server) : le LLM appelle un outil « rechercher dans mes dossiers » exposé par la Box. Souple, mais l'attaque de la CVE-2026-54016 visait précisément un outil de recherche acceptant un identifiant arbitraire ⁸ : l'outil ne doit accepter aucun identifiant de portée du côté modèle.

Dans les trois cas, la knowledge intégrée d'Open WebUI n'est plus utilisée pour les dossiers ; elle peut rester pour des documents publics (modèles d'actes, doctrine libre).

CVE 2026 et versions corrigées

Limites pour un cabinet

• Contrôle d'accès documentaire applicatif, historique 2026 défavorable.
• Un seul fournisseur OIDC générique à la fois ⁴ : suffisant pour un cabinet, gênant pour une Box multi-clients.
• Pas de « deny » : la modélisation « tout fermé puis ouvrir » est obligatoire et fragile aux ajouts de fonctionnalités (chaque nouvelle permission arrive avec son défaut).
• Partage intra-groupe non gouverné (discussion #15100).
• Surface fonctionnelle large (web search, images, code interpreter, outils directs) à désactiver explicitement.
• Pas de notion de dossier ni de citation page à page native : à apporter par le RAG externe et, à terme, par une interface propre.
• Clause de branding au-delà de 50 utilisateurs ou pour une marque blanche.

Questions ouvertes

• Q-005Open WebUI est-il suffisant comme interface, ou faut-il LibreChat ou une interface propriétaire ?MoyenneEn cours

Ce qu'il reste à tester

• Brancher le RAG de la Box sur Open WebUI (pipeline, endpoint, outil)Un endpoint OpenAI-compatible exposé par le service RAG de la Box, appelé par Open WebUI comme un modèle, transmet l'identité de l'utilisateur de façon vérifiable et affiche les citations (dossier, pièce, page, lien) sans dépendre du RAG intégré ni de ses knowledge bases.À tester
• Test de fuite de permissions du RAG (« l'avocat B ne voit jamais A »)Avec un filtre dossier_id calculé côté serveur et imposé par le moteur (RLS PostgreSQL ou JWT Qdrant), aucun chunk ni aucune réponse ne contient un canari hors de la portée de l'utilisateur, même lorsque la barrière applicative est désactivée.À tester