Провайдеры входа

Раздел Провайдеры задаёт, какими способами пользователи входят в платформу. Доступен администратору.

Состав

Поле	Что означает
Название	Как провайдер подписан на экране входа
Тип	Способ аутентификации
Приоритет	Порядок применения; определяет и порядок кнопок на экране входа
Статус	Активен провайдер или выключен
Создан	Дата добавления провайдера

Типы провайдеров

Тип	Описание
default	Встроенный вход по логину и паролю. Создаётся при установке
openid	Внешний провайдер по протоколу OpenID Connect — например, Keycloak
ldap	Каталог LDAP

Новый провайдер добавляется кнопкой Создать провайдер; при создании доступны типы OpenID и LDAP — встроенный вход существует в единственном экземпляре.

Настройки провайдера

Общие для всех типов:

Настройка	Что задаёт
Создавать пользователя	Заводить ли учётную запись при первом успешном входе. Выключено — войти смогут только те, кого администратор создал заранее
Тип по умолчанию	Какой тип учётной записи получит созданный пользователь: создатель, исследователь, наблюдатель
Группы по умолчанию	В какие группы его добавить сразу
Приоритет	Порядок применения и порядок кнопок на экране входа

Дальше набор зависит от типа.

OpenID: адрес поставщика (issuer), идентификатор клиента, секрет клиента и подпись кнопки на экране входа.

LDAP: адрес каталога, учётные данные для связывания, базовый DN, атрибут связывания (обычно cn), атрибут логина (обычно uid) и дополнительные фильтры поиска.

Active Directory и отечественные каталоги подключаются этим же типом

Отдельного типа провайдера для Active Directory нет — она подключается как LDAP, потому что работает по тому же протоколу. Атрибут логина в этом случае задают свой: sAMAccountName или userPrincipalName вместо uid. Почтовый адрес платформа ищет в атрибутах mail, email и userPrincipalName — в этом порядке, — поэтому у пользователей AD он подтягивается без дополнительной настройки.

Так же подключается любой каталог, говорящий по LDAP, включая отечественные службы каталогов на его основе. Проверьте на своей установке: платформа опирается на протокол, а не на конкретный продукт, и списка сертифицированных каталогов у неё нет.

SAML не поддерживается

Провайдера SAML в платформе нет: доступны встроенный вход, OpenID Connect и LDAP. Если корпоративный вход построен на SAML, потребуется промежуточный провайдер, умеющий отдавать OpenID Connect, — например, Keycloak.

Встроенный вход параметров не принимает: у него настраиваются только общие поля из таблицы выше. Попытка сохранить ему любой параметр отвечает ошибкой «Параметры невалидны для данного типа провайдера».

Проверка подключения

Карточка Проверка справа в форме проверяет настройки, не сохраняя их: нажмите Тестовое подключение, и под кнопкой появится результат. Проверка берёт значения из полей формы прямо сейчас, поэтому годится и для нового, ещё не сохранённого провайдера.

Что именно проверяется:

Тип	Что делает платформа
LDAP	подключается к каталогу учётными данными связывания и ищет в базовом DN запись с атрибутом логина
OpenID	читает .well-known/openid-configuration у поставщика и сверяет, что в документе есть адреса авторизации, выдачи токена и сведений о пользователе
Встроенный вход	проверять нечего — кнопка сообщает, что проверка для этого типа не поддерживается

Успех — зелёная строка «Подключение успешно». Неудача не прерывает работу с формой: платформа показывает, что именно не сошлось.

Сообщение	Где искать причину
«Сервер каталога недоступен по адресу …»	адрес и порт каталога, доступность сервера с сервера платформы
«Сервер отклонил учётные данные сервисной записи»	логин и пароль связывания; в скобках платформа показывает, под каким именем подключалась
«Подключение прошло, но база поиска … в каталоге не найдена»	базовый DN
«Подключение прошло, но в … нет ни одной записи с атрибутом …»	атрибут логина или фильтры поиска: под них не подходит ни один пользователь
«Не удалось прочитать .well-known/openid-configuration по адресу issuer_uri»	адрес поставщика и его доступность с сервера платформы
«Провайдер отдаёт issuer …, а в настройках указан …»	поставщик за обратным прокси отдаёт внутренний адрес — приведите адреса к одному виду
«Провайдер доступен, но не отдаёт … в discovery-документе»	настройки самого поставщика: вход использует эти адреса

Успешная проверка не заменяет пробный вход

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

Что попадает в платформу при входе

Из внешнего провайдера платформа берёт логин и почту. У OpenID логин ищется по очереди в login, preferred_username, username, email, sub — первое найденное; у LDAP почта берётся из mail, email или userPrincipalName.

Должность, подразделение и телефон не переносятся — платформа их не хранит, см. Профиль.

Атрибуты для видимости строк

У обоих внешних типов — и у LDAP, и у OpenID — в форме провайдера есть карточка Атрибуты пользователя (RLS). В ней перечисляется, какие данные провайдера становятся атрибутами учётной записи. Именно эти атрибуты подставляются в правила видимости строк вида «Атрибут пользователя» — так, например, менеджер видит только свой регион, а список регионов ведётся у провайдера, а не в платформе.

Строка сопоставления состоит из четырёх полей:

Поле	Что задаёт
Атрибут	Имя атрибута внутри платформы — на него ссылается правило видимости строк
Claim провайдера	Что взять на стороне провайдера: claim токена у OpenID, атрибут каталога у LDAP
Список	Значение содержит несколько значений, а не одно
Разделитель	Чем они разделены, если пришли одной строкой. Доступен только при включённом «Список», по умолчанию запятая

Значения записываются при каждом входе через этот провайдер и заменяют прежние. Атрибуты, заданные администратором вручную в карточке пользователя, вход не затирает. Изменение в каталоге или IdP вступает в силу со следующего входа пользователя.

Забытый атрибут не даёт ошибки

Провайдер отдаёт только то, что у него запросили. Если атрибут не указан в сопоставлении, он останется пустым, и платформа не сообщит об этом. Пустой атрибут в правиле видимости строк закрывает пользователю все строки. Проверяйте связку «атрибут у провайдера → сопоставление → правило» целиком.

Ошибка в самом сопоставлении вход тоже не прерывает: платформа оставляет прежние атрибуты и пишет предупреждение в журнал сервиса. Внешне это выглядит так, будто правило перестало пропускать пользователя, а причина — в настройке провайдера.

Почему не пустило пользователя

Если вход через провайдера не удался, платформа возвращает человека на страницу входа с объяснением. По тексту видно, где искать причину:

Сообщение	Что произошло
«Учётная запись не зарегистрирована в системе. Обратитесь к администратору»	Пользователя в платформе нет, а автосоздание у провайдера выключено — включите Создавать пользователя или заведите учётную запись заранее
«Вход через этого провайдера сейчас невозможен: он настроен неверно. Обратитесь к администратору»	Ошибка в настройках провайдера: адрес поставщика, идентификатор или секрет клиента
«Вход через провайдера истёк — начните заново», «Ссылка для входа устарела — начните вход заново»	Пользователь слишком долго был на стороне провайдера или открыл старую ссылку; достаточно повторить вход
«Ответ провайдера не соответствует начатому входу — начните заново»	Вход начат в одной вкладке, а завершён в другой, либо ответ пришёл с чужими параметрами

Что учесть

• Выключенный провайдер не показывается на экране входа, но его настройки сохраняются.
• Для OpenID на стороне внешнего провайдера нужно разрешить адрес возврата, по которому платформа завершает вход.
• Адрес, куда платформа уводит браузер после внешнего входа, задаётся при развёртывании отдельной настройкой (AUTH_FRONTEND_BASE_URL) — это адрес интерфейса, а не адрес API. Если её не задать, возврат уйдёт на адрес API, где страницы входа нет, и вход завершится отказом. Симптом со стороны пользователя: провайдер сообщает об успехе, а платформа показывает ошибку доступа.
• Встроенный вход выключить нельзя: платформа отвечает «Нельзя отключить default провайдер». Так остаётся способ войти, даже если внешний провайдер откажет.

Что дальше

• Пользователи и группы — что происходит с учётной записью после входа.
• Управление доступом — какие права получает вошедший.