Перейти к основному содержимому

Провайдеры идентификации

Planeon аутентифицирует всех — и администраторов, и конечных пользователей — через стандартный OpenID Connect. Собственного провайдера идентификации в поставке нет, как и локального хранилища паролей: вы указываете Planeon на свой собственный OIDC-совместимый провайдер, и подходит любой провайдер, который публикует discovery-документ OpenID и умеет выдавать claim групп, — Keycloak, Microsoft Entra ID, Okta, Authentik и другие.

Как работает вход​

Провайдер идентификации отвечает на вопрос «кто этот пользователь?»; собственное управление доступом Planeon отвечает на вопрос «что ему здесь можно?». При входе:

  1. Ваш провайдер идентификации выдаёт браузеру пользователя OIDC-токен.
  2. Planeon проверяет issuer, audience, подпись и срок действия токена.
  3. Planeon читает личность пользователя (subject, email, имя, имя пользователя) и два настраиваемых claim'а — claim групп и claim ролей.
  4. Эти claim'ы сохраняются как внешние факты о пользователе; они становятся локальным доступом только после сопоставления через OIDC-привязку групп.

Настройка стандартного OIDC​

Любой провайдер настраивается одним и тем же небольшим набором значений:

  • Redirect URIs — зарегистрируйте у своего провайдера идентификации три URI приложения, все на origin вашего Planeon (здесь показан как https://<хост-вашего-planeon>; для локальной установки используйте http://localhost:3000):

    • https://<хост-вашего-planeon>/auth/callback — куда провайдер возвращает пользователя после входа.
    • https://<хост-вашего-planeon>/auth/signed-out — видимая страница после выхода; провайдеры сверяют post-logout-редирект с этим зарегистрированным списком.
    • https://<хост-вашего-planeon>/auth/frontchannel-logout — URL front-channel-уведомления о выходе, который провайдер загружает (незаметно), чтобы очистить локальное состояние входа Planeon, когда сессия завершается на стороне провайдера.

    Если зарегистрирован только /auth/callback, вход будет работать, а выход — ломаться: обычно с ошибкой провайдера вида «Bad Request: The request is otherwise malformed», когда post-logout-редиректа нет в списке разрешённых.

  • Client ID / secret — фронтенд Planeon — это одностраничное браузерное приложение, поэтому оно аутентифицируется как публичный OIDC-клиент (PKCE, без client secret), а не конфиденциальный. Зарегистрируйте публичный клиент и используйте один и тот же client ID и во фронтенде, и в бэкенде.

  • Issuer URL — точный URL, который ваш провайдер помещает в claim iss токена. Браузер должен иметь возможность напрямую обратиться к <issuer>/.well-known/openid-configuration, поэтому избегайте здесь внутренних адресов или адресов, доступных только внутри контейнерной сети.

  • Scopes — openid profile email groups offline_access. Scope offline_access — это то, что позволяет вашему провайдеру выдавать refresh-токен, благодаря чему давно открытая вкладка браузера может тихо продлить сессию, вместо того чтобы отваливаться при истечении access-токена.

  • Claim группы — claim, который Planeon читает для определения членства в группах, по умолчанию groups. У провайдеров с вложенными claim'ами (например, у ролей realm в Keycloak) можно читать значение по dot-path вида realm_access.roles вместо простого ключа верхнего уровня. Какой бы claim вы ни настроили, помните: сам по себе claim ничего не даёт, пока вы не сопоставите его значения с локальными группами через OIDC-привязку групп.

Проверенные провайдеры​

Keycloak. Keycloak выдаёт роли realm вложенными в realm_access.roles, а роли клиента — в resource_access.<client-id>.roles; группам нужен явный маппер «Group Membership», добавленный к клиенту (или общему client scope), чтобы попасть в токен, обычно как claim groups верхнего уровня. Issuer — https://<хост-keycloak>/realms/<realm>. Если в мапперe отключить опцию «Full group path», пользователь в группе /VDI-Admins выдаст простое значение VDI-Admins, без пути с ведущим слэшем.

Microsoft Entra ID. Используйте endpoint версии v2.0: https://login.microsoftonline.com/<tenant-id>/v2.0. Claim groups у Entra по умолчанию содержит GUID объектов групп, если вы не настроите его на выдачу отображаемых имён; более надёжный вариант — привязка на app roles (claim roles) вместо сырых групп. Учитывайте лимит переполнения групп — у пользователя примерно в 200+ группах claim groups в токене вообще отсутствует, вместо него — только указатель на Microsoft Graph API, за которым Planeon не следует; привязка на app roles полностью обходит эту проблему.

Okta. Стандартный «org»-authorization server у Okta не выдаёт пригодный claim групп, поэтому используйте кастомный Authorization Server (подходит и встроенный default) и явно добавьте к нему claim групп. Issuer — https://<ваш-org>.okta.com/oauth2/<authorization-server-id>, а Okta выдаёт groups как обычный JSON-массив строк, без какой-либо особой обработки на стороне Planeon.

Authentik. Authentik — провайдер идентификации, который собственный стек локальной разработки Planeon поставляет за необязательным профилем, — это удобный вариант по умолчанию, а не требование. Ему не нужно ничего специфичного сверх стандартного рецепта OIDC выше: создайте OAuth2/OpenID-провайдер и приложение, задайте публичный тип клиента, включите Authorization Code grant с PKCE и добавьте маппинг scope групп, чтобы членство в группах попадало в токен.

Что дальше​

Подробные пошаговые руководства по настройке для каждого из этих провайдеров планируются как дополнения к этой странице.