Аутентификация

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

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

Обычная конфигурация балансировки пропускает всех, кто обращается по опубликованному адресу. Аутентификация превращает такую конфигурацию в закрытую: запрос без учётных данных на бэкенд не передаётся.

Из чего состоит

Настройка держится на четырёх объектах кластера балансировки:

В боковом меню кластера балансировки раздел Аутентификация содержит три вкладки — Профили, Наборы пользователей и Провайдеры. Привязка профиля к сервису настраивается отдельно, в конфигурации балансировки. В GSLB-кластере аутентификации трафика нет.

Набор пользователей нужен не для каждого профиля. Там, где клиент приходит уже с подписанным токеном от внешнего поставщика идентификации — Keycloak, Azure AD, Okta, — пароли в системе 5А не хранятся, и набор можно не создавать.

Привязка работает только на сервисах с L4-протоколом TCP и L7-протоколом HTTP или HTTPS. Для других сочетаний протоколов секция Аутентификация на вкладке Безопасность не показывается. Сервис с протоколом gRPC попадает под это ограничение: профиль к нему привязать нельзя, и запросы к такому сервису проходят без проверки учётных данных.

Название и описание

У профилей аутентификации, наборов пользователей и провайдеров два общих поля.

Все поля, отмеченные , являются обязательными для заполнения.

• Название — имя, по которому объект выбирают в списках и в привязках. Уникально в пределах кластера: на повтор система отвечает, что объект с таким именем уже существует.
• Описание — произвольный текст для администратора, на проверку не влияет. Пустое значение показывается в таблице прочерком.

Порядок настройки

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

2. Создайте профиль аутентификации и выберите в нём модули: как балансировщик примет учётные данные, чем проверит и что отдаст на бэкенд.

3. Привяжите профиль к сервису на вкладке Безопасность его конфигурации балансировки. В привязке укажите, какие пути закрыть и какие группы пропускать.

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

Для входа через внешнюю систему идентификации порядок другой: сначала создаётся провайдер аутентификации, затем профиль с модулями oidc. Полный порядок — в статье Вход через внешний провайдер (OIDC).

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

Типовые задачи

Закрыть сервис паролем

Задача: опубликованный сервис открыт всем, кто знает адрес. Нужно пускать только сотрудников с логином и паролем.

1. Создайте набор пользователей с логинами сотрудников. Сотрудникам, которым доступен не весь сервис, задайте общую группу, например office.

2. Создайте профиль аутентификации: в блоке Приём учётных данных добавьте модуль basic, в блоке Проверка — local_db и укажите набор, в блоке Передача на бэкенд — header.

3. Привяжите профиль к сервису с областью применения Весь сервис.

Клиент без заголовка Authorization получит отказ, и запрос на бэкенд передан не будет. Клиентский сервер при этом получит заголовки X-Auth-User и X-Auth-Groups и увидит, кто именно обратился.

Открыть админку отдельно от основного сервиса

Задача: основной сервис открыт всем аутентифицированным сотрудникам, а административный интерфейс — только группе admins. Оба пути обслуживает один и тот же клиентский сервер.

1. Создайте набор пользователей с двумя группами: office для всех и admins для сотрудников с доступом к админке.

2. Создайте один профиль аутентификации — он может и принять пароль, и передать имя пользователя и группы заголовками.

3. Добавьте в конфигурацию балансировки две привязки этого профиля: первую с областью Кроме путей и пути админки, вторую — только на эти пути с разрешённой группой admins.

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

Пускать клиентов с токеном внешнего провайдера

Задача: сотрудники входят во внешнюю систему и получают там подписанный токен. На второй сервис они должны попадать без повторного ввода пароля.

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

2. Создайте профиль аутентификации: в блоке Приём учётных данных — модуль jwt, в блоке Проверка — jwt с источником ключа Набор ключей провайдера (JWKS). Если провайдер кладёт токен не в Authorization, задайте источник в настройках модуля jwt.

3. Проверьте имена утверждений: в Утверждение с именем пользователя и Утверждение со списком групп должны стоять имена полей токена провайдера. Если поля пустые, используются sub и groups.

4. В блоке Передача на бэкенд добавьте модуль header, чтобы приложение получило имя пользователя и группы отдельными заголовками.

5. Привяжите профиль к сервису, указав требуемые группы, если доступ к сервису не для всех.

Набор пользователей при этом не создаётся: пароли в системе 5А не хранятся, проверяется только подпись токена.

Пускать клиентов через внешнюю систему идентификации

Задача: сотрудники входят в Keycloak или Entra ID, а приложение должно получать имя пользователя и группы без единого пароля в системе 5А.

1. Создайте провайдера аутентификации с адресом вашей системы входа и нажмите Получить сведения, чтобы подставить адреса эндпоинтов, адрес набора ключей и свойства провайдера из метаданных.
2. Создайте профиль аутентификации с модулями oidc в блоках Приём учётных данных и Проверка, укажите провайдера и ID клиента с Секретом клиента из регистрации в Keycloak.
3. Проверьте имена полей токена: в Поле токена с пользователем и Поле токена с группами должны стоять имена, которые использует ваш провайдер. У Keycloak группы лежат во вложенном поле realm_access.roles.
4. Сохраните профиль, привяжите его к сервису и передайте администратору Keycloak адрес возврата из секции Регистрация у провайдера.

Подробный порядок с примерами — в статье Вход через внешний провайдер (OIDC).

Передать имя пользователя и завершить выход

Задача: приложение ведёт сессию само и показывает пользователю кнопку Выйти. После выхода приложение не должно тут же создать новую сессию для того же пользователя.

1. Создайте профиль аутентификации с модулем form в блоке приёма и на вкладке Сессии включите сессии.

2. В привязке профиля добавьте адреса выхода приложения, например /logout, и оставьте область применения Весь сервис.

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

Что проверить

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

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

2. Повторите запрос с верными учётными данными — ожидается штатная страница приложения.

3. Посмотрите заголовки запроса, отправленного на клиентский сервер: в них должны быть X-Auth-User и X-Auth-Groups с именем пользователя и его группами.

Если вместо отказа приходит страница приложения, профиль не привязан к этому сервису либо область применения привязки его не покрывает.