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

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

Статус документа

OIDC-вход, dev identity и локальные назначения уже реализованы. Разделы с пометкой «Проект» описывают предлагаемое внешнее управление правами. Они предназначены для согласования до изменения кода. Названия новых параметров, формат YAML и внешний диалог пока не являются доступными возможностями продукта.

Способы входа

Способ	Применение	Подробная настройка
OIDC	Пользовательский вход через Keycloak или совместимого провайдера	OIDC
Dev identity	Фиксированный пользователь в изолированной среде разработки	Режим разработки

Dev identity — специальный режим backend. Service Backend также принимает Bearer JWT, проверяемый OIDC-механизмом; отдельного интерактивного входа по произвольному токену или Basic Auth у него нет.

Настройка входа в конфигуратор принадлежит backend. Документы AuthProfile внутри workspace настраивают аутентификацию runtime-интеграций конечного приложения; они не выбирают источник административных прав самого конфигуратора.

Bearer JWT для API

Для прямого запроса к Service Backend в OIDC-режиме передайте выданный провайдером JWT в HTTP-заголовке:

Authorization: Bearer <access_token>

Backend проверяет подпись, issuer, audience и срок действия согласно настройкам OIDC. Произвольный непрозрачный токен или Basic Auth для этого входа не поддерживаются. При внешнем управлении правами проверенный access token также служит источником маппинга назначений.

Роли конфигуратора

Область	Роль	Назначение
Платформа	Admin	Администрирование платформы и доступ ко всем workspace
Workspace	Admin	Администрирование выбранного workspace, включая доступные ему административные операции
Workspace	Editor	Чтение и изменение конфигураций выбранного workspace
Workspace	Viewer	Чтение конфигураций выбранного workspace

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

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

Локальные назначения: текущий режим

Backend хранит пользователей и назначения доступа в своей БД. Администратор управляет назначениями через конфигуратор, backend проверяет его полномочия. Пользователь может входить через OIDC и при этом получать роли из локальной БД.

Текущая реализация имеет специальный bootstrap первого активного пользователя и настройки AUTH_PLATFORM_ADMIN_SUBJECTS / AUTH_PLATFORM_ADMIN_GROUPS, способные создать локального Platform Admin. Это постоянное локальное назначение, а не полная синхронизация внешних прав. Исчезновение группы из токена само по себе не удаляет созданное назначение.

Проект: единственный источник управления правами

Предлагается выбрать один режим на экземпляр backend при его запуске:

	local	external
Кто задаёт назначения	Администратор Endge	Внешний источник через адаптер и маппинг
Что хранит БД Endge	Локальные назначения	Производный набор внешних назначений
Что показывает конфигуратор	Управление доступом	Мои права доступа
Можно ли вручную менять назначения через API	Да, с проверкой административной роли	Нет, включая Platform Admin
Когда обновляются назначения	При локальном изменении	При получении и проверке нового токена

Локальных override нет. Внешние назначения полностью заменяют прежний набор пользователя, включая удаление исчезнувших прав. Файл маппинга описывает соответствие атрибутов ролям Endge; назначения пользователей во внешней системе остаются единственным управляемым источником.

Выбор режима, ошибки запуска и смена конфигурации описаны в проекте файла внешних прав.

Проект: получение и синхронизация прав

Во внешнем режиме backend сначала проверяет identity и токен, затем преобразует claims и заменяет назначения пользователя в одной транзакции. Только после успешной синхронизации выполняется защищённая операция. Проверки доступа и конфигуратор читают результат из БД Endge.

Синхронизация выполняется при входе и получении нового токена через refresh. Для Bearer-запросов новый проверенный токен проходит тот же маппинг до использования назначений. Повторные запросы с уже обработанным токеном не требуют повторной записи одинакового набора.

Ошибка проверки токена не даёт доступа. Ошибка синхронизации не разрешает продолжить запрос с прежними правами. Если корректный токен не даёт ни одного назначения, прежние назначения удаляются; пользователь остаётся аутентифицированным, но не получает доступ к workspace.

Снимок назначений не заменяет действующую сессию или токен. Повторная доставка старого токена или параллельный refresh не должны откатывать уже применённый более свежий снимок. Устаревшая сессия также не должна переписывать права после смены конфигурации.

Проект: допустимая задержка отзыва

Мгновенный отзыв уже выданных JWT не требуется. Допускается использование действующего токена до истечения его срока. Проверка того же JWT не запрашивает актуальные права в Keycloak: изменённые права приходят в новом токене.

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

Для длительных соединений срок авторизации также должен соблюдаться: открытый поток не получает бессрочный доступ только потому, что токен был действителен при подключении. Конкретная интеграция проверяется при реализации соответствующего transport.

Проект: диалог в конфигураторе

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

При external вместо него открывается «Мои права доступа», доступное любому аутентифицированному пользователю, в том числе до выбора workspace. Оно показывает только текущего пользователя и его итоговый доступ Endge:

Доступ управляется внешней системой
Источник: Корпоративный Keycloak
Права обновляются автоматически при входе и обновлении сессии.
Последняя синхронизация: сегодня, 12:05.

Область	Пример отображения
Платформа	Администратор или «Нет административного доступа»
Workspace «Операции»	Редактор
Workspace «Аналитика»	Наблюдатель

У Platform Admin дополнительно показывается «Доступ ко всем рабочим пространствам», чтобы отдельные назначения не выглядели ограничением общей роли. При пустом наборе выводится «Доступ к рабочим пространствам не предоставлен».

Поиск других пользователей, элементы редактирования и переключатель режима отсутствуют. Raw JWT и исходные claims не показываются. Открытие окна читает текущую проекцию и само по себе не запускает принудительный refresh.

Проект: граница backend API

Режим хранится в памяти backend после запуска и передаётся frontend вместе с данными сессии. Предлагаемый фрагмент session response:

{
  "accessManagement": {
    "mode": "external",
    "sourceName": "Корпоративный Keycloak",
    "lastSynchronizedAt": "2026-09-09T09:05:00Z"
  }
}

В локальном режиме достаточно {"mode":"local"}. Это дополнение к session response, а не новый источник ролей: итоговые роли возвращаются из того же расчёта, которым защищается API. Имя источника относится к текущей identity выбранного backend; сведения о чужих пользователях для этого экрана не нужны.

Use case ручного изменения назначения проверяет режим и возвращает 403 с кодом access_managed_externally и сообщением «Права доступа управляются внешней системой». Проверка действует для создания, изменения, удаления, массовых операций и других публичных путей изменения membership или назначений, включая import/restore. Остальные документы workspace остаются редактируемыми в соответствии с ролью.

Внутренняя синхронизация остаётся разрешённым способом записи. Во внешнем режиме bootstrap первого администратора и legacy-настройки Platform Admin не создают назначения в обход маппинга; защита последнего локального администратора не препятствует внешнему отзыву.

Проект: развитие адаптеров

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

Первый вариант файла рассчитан на один настроенный источник backend. Возможность подключить другой адаптер не означает автоматическое объединение нескольких источников в одной сессии. Несколько одновременных провайдеров потребуют отдельного контракта выбора и связывания identity; совпадение email или username не является основанием для объединения аккаунтов.

Для входа в конфигуратор существуют OIDC и dev-режим. Вход через SAML или LDAP напрямую не реализован.