Open WebUI с LDAP или SSO: вход сотрудников и проверка прав

Когда нужен LDAP, а когда SSO?

Если организация уже использует каталог LDAP и хочет проверять учётные данные через него, начните с LDAP-конфигурации Open WebUI s1. Если сотрудники входят через корпоративного поставщика идентификации по OpenID Connect (OIDC), настройте SSO: Open WebUI поддерживает вход через OIDC без LDAP s2 s7. Это альтернативные маршруты для пилота, а не обязательная последовательность «сначала LDAP, затем SSO». Trusted Header за прокси — третий, более чувствительный к настройке доверенной границы маршрут; в нём прокси должен удалять присланные клиентом заголовки и вставлять собственные s2 s5. Его здесь не настраиваем.

Результат пилота: два заранее созданных тестовых сотрудника входят через выбранный маршрут; одному выдано чтение тестовой модели, второму — нет. Авторизация в интерфейсе и права на конкретную модель — разные проверки s3 s4. Вход не доказывает права на отдельные фрагменты документов, корректность ответов модели или отсутствие облачных соединений. Не загружайте персональные данные до собственного теста доступа и сети.

Что подготовить перед настройкой?

Поднимите Open WebUI на проверенной вашей командой версии с отдельным сохраняемым томом /app/backend/data и стабильным WEBUI_SECRET_KEY, как описано в руководстве Docker; не публикуйте пароль, ключ сессий или client secret в примере, репозитории и shell history s6 s5. Сначала проверьте, что локальный runtime отвечает через интерфейс: страница установки Open WebUI описывает подключение Ollama как отдельного endpoint, а сама веб-оболочка не заменяет inference-сервер s6. Выберите одну конкретную модель, доступную обоим тестовым пользователям только после выдачи grant, и зафиксируйте её тег/версию и адрес локального runtime.

Для корпоративной сети заранее определите URL веб-интерфейса, TLS на обратном прокси, сетевую границу/VPN и администратора начальной установки: руководство hardening описывает прокси как точку HTTPS и рекомендует ограничивать доступ к экземпляру s5. Для OIDC отдельно понадобятся контролируемый IdP, клиент, разрешённый redirect URI и возможность хранить secret вне текста статьи s2. Для LDAP понадобятся адрес сервера, база поиска, атрибуты пользователя и права bind-учётки s1. Если корпоративная политика запрещает обращение к внешнему IdP, это нужно проверять отдельно: «локальная модель» не означает «вся аутентификация офлайн».

Как настроить LDAP без открытого пароля?

Выберите в Admin Panel → Settings → Authentication → LDAP уже работающего тестового экземпляра и укажите параметры своего каталога. Документация перечисляет ENABLE_LDAP, LDAP_SERVER_HOST, LDAP_SERVER_PORT, LDAP_APP_DN, LDAP_APP_PASSWORD, LDAP_SEARCH_BASE, LDAP_ATTRIBUTE_FOR_USERNAME и LDAP_ATTRIBUTE_FOR_MAIL; сервер и атрибуты нужно взять у администратора каталога, а пароль передать через принятый в вашей инфраструктуре механизм секретов s1. Не копируйте демонстрационные admin и localhost как production-значения.

Для передачи LDAP-учётных данных рекомендуемая конфигурация hardening — LDAPS с LDAP_USE_TLS=true, LDAP_VALIDATE_CERT=true и доверенным CA s5. В LDAP-гайде указаны порт 636 для LDAPS, различие между TLS и простым портом 389, а также отсутствие StartTLS у этого переключателя s1. В тесте проверьте сертификат, а не отключайте проверку ради прохождения входа. LDAP_SEARCH_FILTER может дополнительно фильтровать разрешённую группу, но не является заменой прав на ресурсы внутри Open WebUI s1 s4.

При первом запуске переменные LDAP считываются в конфигурацию; на уже созданном экземпляре последующие изменения вносите через админ-панель, если только сознательно не отключён persistent config s1. Откройте отдельное окно браузера и войдите тестовой учёткой: новый пользователь получает роль по текущей политике экземпляра; default pending требует одобрения администратора s1 s3. Если вход не проходит, проверьте отдельно разрешение имени и порт, сертификат и bind-креденшелы; серверное сообщение err=49 в гайде означает отказ LDAP по учётным данным, не проблему с моделью s1. Не вставляйте реальные пароли в опубликованные команды диагностики.

Как настроить SSO/OIDC вместо LDAP?

Для тестового OIDC-клиента укажите OPENID_PROVIDER_URL (адрес discovery), OAUTH_CLIENT_ID, OAUTH_CLIENT_SECRET и WEBUI_URL; на стороне IdP зарегистрируйте точный <адрес-webui>/oauth/oidc/callback или соответствующий явно заданный OPENID_REDIRECT_URI s2. Проверьте наличие email claim и доступность discovery из контейнера, не подставляя несуществующие переменные вроде OIDC_CONFIG s2. ENABLE_OAUTH_SIGNUP отвечает за создание аккаунта после OAuth-входа отдельно от ENABLE_SIGNUP; выбирайте его и стартовую роль по политике пилота, а не автоматически разрешайте любого сотрудника IdP s2 s3.

На ревизии документации OAuth-настройки по умолчанию читаются из environment: при ENABLE_OAUTH_PERSISTENT_CONFIG=false раздел OAuth в админ-панели только для чтения; при изменении env перезапустите приложение. Чтобы управлять настройками из панели и сохранять их в базе, нужны ENABLE_OAUTH_PERSISTENT_CONFIG=true и включённый ENABLE_PERSISTENT_CONFIG s2. Стабильный WEBUI_SECRET_KEY требуется для сессий, особенно если реплик больше одной s2 s5. Не включайте OAUTH_MERGE_ACCOUNTS_BY_EMAIL без отдельного решения о доверии к подтверждению email у IdP: документация отмечает риск ошибочного связывания аккаунтов s2.

Только после успешного входа администратора и тестового пользователя через OIDC можно отключать локальный экран входа (ENABLE_LOGIN_FORM=false) и, если нужен полностью SSO-only путь, серверную password-аутентификацию (ENABLE_PASSWORD_AUTH=false); сохраните согласованный аварийный порядок доступа до переключения s5 s7. Для SSO-only не требуется включать LDAP. При ошибке redirect_uri сначала сравните URL запроса и запись клиента в IdP, а не отключайте безопасность s2.

Как разделить две роли и доступ к модели?

Системные роли Open WebUI — admin, user, pending; admin по умолчанию имеет широкие полномочия, pending не получает рабочий доступ s3. Для проверки возьмите двух обычных пользователей user, а не администратора как «положительный» тест: его стандартный обход ACL исказит результат s3 s4. Создайте тестовые группы «Пилот» и «Контроль» в Admin Panel → Users → Groups; дайте только «Пилоту» право чтения Private тестовой модели. Для группы «Контроль» не выдавайте этот grant, не оставляйте wildcard/Public и убедитесь, что у сотрудника нет другой группы или прямого grant на ту же модель s4.

Права групп аддитивны: запрет в одной группе не отменяет grant другой; отсутствие deny-групп важно при разборе неожиданного доступа s4. Отдельно различайте право пользоваться функцией (например, Knowledge Access) и grant на конкретную модель или knowledge base: это разные слои s8 s4. Включение SSO само не включает документный ACL. Если используете OIDC group claims, ENABLE_OAUTH_GROUP_MANAGEMENT синхронизирует членство при входе и может удалить локально назначенные группы, которых нет в непустом claim; перед включением проверьте состав claims s2. Для LDAP-пилота назначьте группы вручную и проверьте их в Open WebUI; не предполагайте, что LDAP-группа автоматически стала группой доступа к модели s1 s4.

Каким тестом подтвердить результат и границы?

1. В пустом профиле браузера войдите аккаунтом «Пилот». Убедитесь, что выданы роль user, группа «Пилот», доступ к одной тестовой модели и ответ на безличный контрольный запрос. Зафиксируйте модель, runtime, версию Open WebUI, путь входа и результат — это собственный протокол пилота, а не тест Modelium.
2. В другом профиле войдите аккаунтом «Контроль» той же системной роли. Проверьте отсутствие тестовой модели в интерфейсе и отказ при прямом обращении к ней через API, если у вашей установки есть авторизованный тестовый способ такого обращения. Admin-only Preview Access показывает итоговые grants модели/knowledge/tool для пользователя; используйте его для аудита, но не вместо отрицательного запроса s4.
3. Снимите grant у первого пользователя или переведите его в pending, повторите проверку с уже открытой вкладкой и с новым запросом. В документации роль pending отказывает в запросах, изменения роли пересматриваются для REST; group grant и роль проверяйте как разные события s3 s4.
4. Если для модели прикреплена база знаний, отдельно проверьте доступ к Private knowledge base и проверяемость ответа на тестовые документы под обоими аккаунтами. Документация отличает scoping прикреплённых баз от видимости ресурса; тест одной модели не подтверждает фильтрацию документов внутри общей коллекции s4. Для документов со смешанными правами нужен отдельный пилот поиска на уровне документа.

Если «Контроль» видит модель, разберите Public/wildcard grant, другие группы, прямой grant и системную роль прежде, чем менять LDAP/SSO s4. Если пользователь входит, но не видит ничего, проверьте pending, выбранную модель/runtime и права на функции; сбой входа и сбой прав — разные причины s3 s8. Если после выхода сеанс остаётся пригодным, проверьте политику JWT/Redis: руководство hardening прямо предупреждает, что без Redis выход не аннулирует токен до истечения, хотя изменение роли пересматривается на запросе s5 s3. Не утверждайте, что один успешный тест доказывает безопасность всей установки.

Как откатить пилот и что делать дальше?

Снимите тестовые grants, удалите ненужные тестовые аккаунты/группы по регламенту, отмените тестовый OIDC-клиент или LDAP bind-учётку и убедитесь, что администратор сохранил рабочий вход. Не меняйте WEBUI_SECRET_KEY как обычную чистку: его замена завершит существующие сессии s5. Экземпляр с настоящими разговорами и файлами не удаляйте вместе с volume /app/backend/data, пока не выполнены резервное копирование и политика хранения s6.

Основной следующий шаг: подготовить Open WebUI и локальный runtime, проверить контрольный ответ модели и только затем повторить описанный тест под двумя аккаунтами. Для полностью закрытого контура отдельно проверьте сетевые вызовы: сам факт входа по LDAP/SSO не доказывает отсутствие внешних подключений.