Авторизация пользователей#

В форме "Пользователь" необходимо выбрать способ входа: локальный, LDAP или OpenID. Для LDAP и OpenID предварительно настраивается подключение к провайдеру на сервере Sherpa Orchestrator.

Скриншоты показывают русскую версию интерфейса. Они иллюстрируют только выбор способа входа. Остальные параметры Пользователя описаны в статье об экране "Пользователи".

Настройки подключения LDAP и OpenID выполняет администратор сервера. Они позволяют Оркестратору проверять учетные записи во внешней системе при входе. Эти параметры нужны, если в организации используется LDAP или OpenID. Для локального входа по логину и паролю настраивать такое подключение не требуется.

Применение настроек авторизации#

При установке через Docker администратор меняет параметры в файле .env в каталоге установки Оркестратора. При локальной установке параметры задаются в backend/config/config.ini под соответствующими именами конфигурации. После изменения этого файла приложение необходимо перезапустить.

Для применения изменений .env в Docker необходимо пересоздать контейнер приложения из каталога установки. Команда ниже временно прерывает работу приложения, но не пересоздает БД:

docker compose up -d --no-deps --force-recreate orchestrator

Локальная авторизация#

Для входа по логину и паролю необходимо выбрать флаг "Локальная".

Пример: в поле "Логин" указано docs.user, в поле "Пароль" введен пароль этой учетной записи. Пароль отображается точками. Выбран флаг "Локальная".

LDAP-аутентификация#

Для входа с учетной записью каталога необходимо выбрать флаг "Использовать LDAP аутентификацию", затем Пользователя в поле "Пользователи LDAP". На скриншоте показан выбранный способ входа. Учетная запись из каталога еще не выбрана.

Для подключения к каталогу LDAP администратору необходимо заполнить следующие параметры в .env:

• LDAP_SERVER — адрес сервера каталога, в котором хранятся учетные записи.
• LDAP_PORT — порт подключения. Его значение зависит от способа защиты соединения, описанного далее.
• LDAP_BASE_DN — раздел каталога, в котором Оркестратор ищет учетные записи.
• LDAP_GROUP — организационное подразделение внутри LDAP_BASE_DN, в котором выполняется поиск.
• LDAP_FILTER — условие отбора учетных записей. Ограничивает результаты поиска и применяется при входе.
• LDAP_UID_KEY — имя атрибута каталога, по которому определяется Пользователь, например uid.

Если каталог требует отдельную учетную запись для поиска пользователей, администратору необходимо настроить ее учетные данные.

Для защиты соединения с каталогом используется шифрование. Способ подключения и порт администратору необходимо согласовать с настройками LDAP-сервера:

• StartTLS — включает шифрование после подключения к серверу. Для него указывается LDAP_ENCRYPTION=tls, обычно используется порт 389.
• LDAPS — устанавливает зашифрованное соединение сразу. Для него указывается LDAP_ENCRYPTION=ssl, обычно используется порт 636.

Сертификат LDAP-сервера должен быть доверенным на сервере Оркестратора. Дополнительные параметры задают проверку сертификата и время ожидания:

• LDAP_TLS_CACERT — путь к файлу или каталогу доверенных сертификатов для проверки LDAP-сервера.
• LDAP_NETWORK_TIMEOUT — время ожидания сетевого соединения с LDAP-сервером.
• LDAP_OPERATION_TIMEOUT — время ожидания выполнения операции в каталоге.

Значения этих параметров администратору необходимо выбрать с учетом сертификатов и времени ответа сервера своей организации. После изменения .env необходимо применить настройки авторизации. Затем проверить вход с учетной записью LDAP.

OpenID-аутентификация#

Для входа через провайдера OpenID необходимо выбрать флаг "Использовать OpenID аутентификацию" и заполнить поле "oAuth id" значением, по которому провайдер определяет Пользователя.

Пример: значение поля sub у провайдера — docs.user. В форме выбран флаг "Использовать OpenID аутентификацию", в поле "oAuth id" указано docs.user.

Чтобы подключить провайдера OpenID — внешнюю систему, которая подтверждает учетную запись при входе, — администратору необходимо задать в .env следующие параметры:

• O_AUTH_CLIENT_ID — идентификатор Оркестратора, зарегистрированного у провайдера.
• O_AUTH_CLIENT_SECRET — секрет для подтверждения Оркестратора у провайдера. Его действительное значение необходимо получить у администратора провайдера и не публиковать.
• O_AUTH_AUTH_URI — адрес страницы провайдера, на которой Пользователь выполняет вход.
• O_AUTH_TOKEN_URI — адрес, по которому Оркестратор получает токен, подтверждающий вход.
• O_AUTH_USER_INFO_URI — адрес получения данных Пользователя у провайдера.
• O_AUTH_SCOPE — запрашиваемые права доступа к данным у провайдера. Заполняется в соответствии с его настройками.

Адреса и значения необходимо получить из настроек приложения, зарегистрированного у провайдера.

У провайдера необходимо зарегистрировать постоянный HTTPS-адрес возврата после входа: https://<домен-оркестратора>/api/v1/system/oauth_hook. Адрес задается в O_AUTH_REDIRECT_URI. Если переменная пустая, адрес сформируется из NGINX_DOMAIN_NAME. Домен и адрес, зарегистрированный у провайдера, должны совпадать.

По умолчанию для связи Пользователя с провайдером используется неизменяемое поле sub (O_AUTH_USER_LINK_FIELD=sub). Если уже настроена другая схема связи или меняется провайдер, необходимо предварительно согласовать перенос существующих учетных записей OpenID: простая смена переменной может лишить пользователей доступа. Установка поддерживает одного настроенного провайдера.

После настройки провайдера необходимо применить настройки авторизации и проверить вход с учетной записью OpenID.

Диагностика отказов входа через OpenID#

Если после возврата от провайдера вход не выполнен, администратору необходимо открыть экран Системные ошибки.

Для просмотра требуется право "Чтение" в строке "Cообщения Роботов" на вкладке "Доступ" Роли. На скриншоте показано это право. Остальные права Роли настраиваются отдельно.

Для поиска отказа требуется запись с каналом oauth и уровнем WARNING. Время записи должно соответствовать попытке входа.

Сообщение OAuth callback failed означает, что вход прервался при возврате от провайдера. В записи stage показывает этап отказа:

• callback — проверка запроса и настроек;
• token — получение токена у провайдера;
• userinfo — получение данных Пользователя;
• identity — проверка значения, по которому определяется Пользователь;
• session — сохранение подтвержденных данных для завершения входа.

Код причины указан в reason. При ошибке связи с провайдером запись также содержит доступные диагностические значения http_status, curl_errno или provider_error.

Пример ошибки конфигурации после начала входа:

OAuth callback failed: stage=callback, reason=not_configured

Для восстановления входа необходимо выполнить следующие действия:

1. Проверить, что идентификатор клиента, HTTPS-адреса обмена токена и получения данных Пользователя, поле связи и адрес возврата настроены корректно. Проверяются O_AUTH_CLIENT_ID, O_AUTH_TOKEN_URI, O_AUTH_USER_INFO_URI, O_AUTH_USER_LINK_FIELD и O_AUTH_REDIRECT_URI.
2. Если настройки менялись во время входа, восстановить согласованную конфигурацию и применить настройки по инструкции применения настроек авторизации.
3. Начать вход заново со страницы авторизации. Повторно открывать прежний адрес возврата нельзя: его состояние уже использовано.

Причина pending_missing означает отсутствие незавершенной попытки входа в текущей сессии. При state_invalid или pending_expired также требуется начать вход заново. Если ошибка повторяется, администратору необходимо проверить сохранение сессии браузера и настройки провайдера.

Сообщение OAuth login failed относится к завершению входа после возврата от провайдера и содержит только этап. Значение verified_identity указывает на отсутствие или истечение подтвержденных данных, user_match — на отказ сопоставления с Пользователем, session — на отказ создания сессии.

В диагностические сообщения не включаются токены, код авторизации, секрет клиента, идентификатор сессии и значение поля связи Пользователя. Для обращения в поддержку достаточно времени ошибки и диагностической записи без добавления этих данных. Успешный возврат от провайдера не создает запись об ошибке. Если ошибка неожиданная, вместо этапа и причины может быть указано только имя класса исключения.