Корпоративный вход: Keycloak и OIDC

Привычный корпоративный вход, общие правила доступа внутри продукта. Для корпоративной поставки geek.moscow можно дополнить единым входом через Keycloak или другой провайдер, совместимый с OpenID Connect (OIDC). Пользователь проходит аутентификацию в системе своей организации, а платформа связывает эту личность с локальным аккаунтом, его типом, компаниями и полномочиями.

Сейчас используется собственная email/password-аутентификация в Identity. Действующий OIDC-адаптер в этой версии отсутствует: подключение провайдера потребует разработки и проверки интеграции. Ниже описан вариант расширения на существующих границах Identity и Gateway.

Что это даст организации

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

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

Как подключается провайдер

Предлагаемый вариант — OIDC Authorization Code Flow с PKCE и серверным обработчиком возврата в Gateway:

Пользователь выбирает корпоративный вход; Gateway создаёт контекст попытки и перенаправляет браузер к разрешённому провайдеру.
Провайдер выполняет вход и возвращает одноразовый код на заранее зарегистрированный callback.
Сервер обменивает код на токены и проверяет подпись, issuer, audience, срок действия, state и nonce.
Identity связывает внешнюю личность с локальным аккаунтом, проверяет его состояние и правила входа.
Платформа выдаёт собственную PRODUCT- или ADMIN-сессию; последующие действия проходят обычные проверки сервисов.

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

Настройки и совместимость

Для Keycloak регистрируется клиент в корпоративном realm. В интеграции задаются issuer и discovery-конфигурация, client ID, метод аутентификации клиента, допустимые callback-адреса и scopes. Серверные секреты хранятся в конфигурации окружения. Для публичного и административного входа предпочтительны отдельные клиенты и адреса возврата.

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

Как сохраняются роли и приватность

Внешняя личность привязывается по паре issuer + subject (iss + sub). Email может измениться, поэтому одного совпадения адреса недостаточно для автоматического объединения с существующим аккаунтом. Привязка существующего аккаунта должна подтверждаться отдельно.

Тип ENGINEER/EMPLOYER, членства в компаниях, назначения на вакансии и согласия на раскрытие остаются в geek.moscow. Если корпоративные группы используются для выдачи прав, применяется явное согласованное сопоставление. Сам факт корпоративного входа не даёт STAFF_MANAGE, доступа к личным данным или прав владельца компании.

ADMIN- и PRODUCT-сессии сохраняют разделение. Для админки проверяются действующая служебная сессия и каждое разрешение. VPN может ограничивать сетевой доступ, а корпоративный SSO — подтверждать учётную запись сотрудника; эти механизмы дополняют друг друга.

Завершение доступа и эксплуатация

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

Интеграционные проверки должны охватить вход, повторный вход, подтверждённую привязку аккаунта, отсутствие лишних прав, выход и отзыв доступа. События входа и ошибки адаптера следует включить в существующие JSON-логи и метрики без записи токенов.

Справочная основа: OpenID Connect Core 1.0 и руководство Keycloak «Securing applications and services with OpenID Connect». Текущее устройство авторизации — в архитектуре, правила продукта — в ролевой модели.

Административный контур · Ролевая модель · Технологии и командная разработка · Все разделы