Методы аутентификации

Методы аутентификации#

Astra Automation может использовать для аутентификации пользователей внешние системы, называемые поставщиками идентификационных данных (Identity Provider, IdP). Далее с целью сокращения они называются провайдерами.

Следующая схема показывает общий порядок обработки входа пользователя в Astra Automation. Конкретный набор шагов зависит от выбранного метода аутентификации.

Общая схема аутентификации в AA Общая схема аутентификации в AA

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

После настройки аутентификация пользователя Astra Automation через провайдер выполняется по следующему алгоритму:

  1. В Astra Automation на странице аутентификации становится доступна кнопка аутентификации с использованием провайдера.

    Примечание

    Количество кнопок и их внешний вид зависят от количества и типов настроенных провайдеров.

  2. При нажатии на кнопку Astra Automation перенаправляет пользователя на страницу аутентификации, заданную в настройках провайдера.

    ../../_images/provider-auth-page.png

  3. Пользователь вводит свои учетные данные на указанной странице. Если идентификация успешна, провайдер перенаправляет пользователя на страницу аутентификации Astra Automation.

    ../../_images/provider-redirect-to-controller.png

    Также провайдер передает в Astra Automation сведения о пользователе и токен, подтверждающий подлинность данных.

  4. Astra Automation проверяет токен и наличие в своей базе учетной записи пользователя.

    Если такой записи нет, она создается на основе данных, полученных от провайдера аутентификации. Запись о пользователе Astra Automation может содержать следующие поля:

    • username – название учетной записи;

    • first_name – имя;

    • last_name – фамилия;

    • email – адрес электронной почты.

    Если для метода аутентификации заданы правила сопоставления, Astra Automation выполняет следующие действия:

    1. Создает организации и команды, отсутствующие в Astra Automation, если методу аутентификации разрешено создавать объекты.

    2. Включает пользователя в организации и команды и назначает ему роли в соответствии с правилами сопоставления.

      Роль, назначаемая на уровне организации или команды, указывается в самом правиле сопоставления.

Примечание

При использовании нескольких методов аутентификации (локальной и внешних, таких как LDAP, SAML, OIDC и другие) возможна коллизия названий учетных записей.

Учетные записи в Astra Automation уникальны в рамках всей системы, при этом каждая внешняя система аутентификации рассматривается как независимый источник учетных записей. Если некоторая учетная запись уже существует в Astra Automation, но на внешнем аутентификаторе была создана учетная запись с таким же названием, то при успешной аутентификации в Astra Automation через новый источник будет создана отдельная учетная запись с автоматически сгенерированным суффиксом (хешем или другим уникальным идентификатором пользователя), например:

admin → admincc1a27e97b7b4886

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

В результате в системе могут существовать несколько учетных записей одного и того же пользователя, отличающихся типом аутентификации (локальная, LDAP, SAML и другие) и набором назначенных ролей.

Список внешних провайдеров аутентификации, поддерживаемых Astra Automation:

Отключение встроенной аутентификации#

В Astra Automation есть функция полного отключения встроенной (локальной) аутентификации. Она позволяет отключить все встроенные учетные записи пользователей для обеспечения входа в систему только через внешние механизмы аутентификации, например, LDAP, SAML, OAuth2 и другие.

Предупреждение

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

  1. Убедитесь, что как минимум один внешний провайдер (LDAP, SAML или другой) настроен и проверен.

  2. Проверьте, что внешнему пользователю назначена роль «Системный администратор» (System Administrator) в Astra Automation.

В случае невыполнения этих действий возможна потеря доступа к Astra Automation.

Чтобы отключить встроенную аутентификацию через графический интерфейс, выполните инструкцию по отключению для метода с названием Local Database Authenticator.

Правила сопоставления#

Членство в организациях и командах, роли и права суперпользователя назначаются пользователям внешних провайдеров с помощью правил сопоставления (Authenticator Maps). Правила сопоставления настраиваются одинаково для всех типов провайдеров и обрабатываются при каждом входе пользователя.

Каждое правило определяется следующими параметрами:

  • Тип сопоставления:

    • Разрешить (Allow) – разрешает вход пользователям, соответствующим триггеру;

    • Организация (Organization) – назначает пользователям роль в указанной организации;

    • Команда (Team) – назначает пользователям роль в указанной команде;

    • Роль (Role) – назначает пользователям роль: системную или в рамках указанной организации или команды;

    • Суперпользователь (Superuser) – назначает пользователям права суперпользователя.

  • Триггер (Trigger) – условие срабатывания правила:

    • Всегда (Always) – правило применяется ко всем пользователям;

    • Никогда (Never) – правило не срабатывает;

    • Группы (Groups) – правило срабатывает при членстве пользователя в указанных группах, полученных от провайдера;

    • Атрибуты (Attributes) – правило срабатывает при совпадении указанных атрибутов, полученных от провайдера.

  • Целевые организация, команда и роль – для типов «Организация», «Команда» и «Роль».

  • Отозвать (Revoke) – если флаг установлен, назначенные правилом права отзываются при утрате соответствия триггеру.

  • Порядок (Order) – числовое значение, определяющее последовательность применения правил.

Организации и команды, указанные в правилах сопоставления и отсутствующие в Astra Automation, создаются автоматически, если в настройках метода аутентификации включена опция Создавать объекты (Create objects).

Роль «Системный аудитор» назначается правилом типа «Роль» (Role) с ролью Platform Auditor. Отдельный тип сопоставления для аудитора не предусмотрен.

Пошаговая инструкция по созданию правил сопоставления приведена в описании создания метода аутентификации.

Azure AD#

Для использования этого провайдера аутентификации необходимы ключ и секрет Azure AD. Пошаговые инструкции по их получению приведены в документации Azure.

Пошаговые инструкции по настройке провайдера через графический интерфейс Astra Automation приведены в описании настройки методов аутентификации.

Ассоциация с организациями и командами#

Членство пользователей Azure AD в организациях и командах Astra Automation и их роли назначаются правилами сопоставления. В качестве триггеров правил используются атрибуты, передаваемые Azure AD, и группы пользователя, получаемые из ключа, указанного в поле Ключ групп (Groups Claim).

Например, для включения членов группы Azure AD в команду Astra Automation создайте правило типа «Команда» (Team) с триггером «Группы» (Groups) и укажите целевые организацию, команду и роль. Для автоматического отзыва роли при утрате соответствия триггеру установите флаг Отозвать (Revoke).

GitHub#

Важно

Эта часть документации находится в стадии разработки.

Google OAuth2#

Важно

Эта часть документации находится в стадии разработки.

Keycloak#

Для аутентификации через Keycloak в Astra Automation предусмотрен отдельный тип метода аутентификации – Keycloak. Описание его полей приведено в инструкции по созданию метода аутентификации.

Также Keycloak можно подключить как провайдера OIDC. Пошаговый пример настройки SSO с помощью OIDC см. в инструкции.

LDAP#

Astra Automation поддерживает использование нескольких конфигураций провайдера аутентификации LDAP одновременно.

Для использования метода аутентификации LDAP необходимы следующие данные:

  • URI серверов LDAP;

  • пароли привязки к LDAP;

  • запрос для поиска пользователей в LDAP;

  • запрос для поиска групп в LDAP.

Для получения этих данных обратитесь к документации используемого провайдера аутентификации LDAP.

Автоматическая синхронизация пользователей LDAP с Astra Automation не выполняется.

При успешной аутентификации в LDAP для пользователя автоматически создается учетная запись в Astra Automation. У созданных таким образом учетных записей нельзя изменить название учетной записи, пароль, имя и фамилию пользователя.

Тип обработчика групп задается в обязательном поле LDAP Group Type. Поддерживаются следующие обработчики:

  • ActiveDirectoryGroupType;

  • GroupOfNamesType;

  • GroupOfUniqueNamesType;

  • MemberDNGroupType;

  • NestedActiveDirectoryGroupType;

  • NestedGroupOfNamesType;

  • NestedGroupOfUniqueNamesType;

  • NestedMemberDNGroupType;

  • NestedOrganizationalRoleGroupType;

  • OrganizationalRoleGroupType;

  • PosixGroupType.

Подробное описание каждого типа обработчика см. в документации библиотеки django-auth-ldap.

Ассоциация данных пользователей#

Настройки ассоциации данных пользователей LDAP с данными пользователей Astra Automation необходимо задавать в поле LDAP User Attribute Map в виде словаря, в котором ключи – названия полей данных пользователя Astra Automation, а значения – названия атрибутов пользователя LDAP, например:

{
  "first_name": "givenName",
  "last_name": "sn",
  "email": "mail"
}

Назначение прав суперпользователя и роли «Системный аудитор»#

Права суперпользователя назначаются пользователям LDAP правилом сопоставления типа «Суперпользователь» (Superuser), например, с триггером «Группы» (Groups), срабатывающим при членстве пользователя в определенной группе LDAP.

Роль «Системный аудитор» назначается правилом типа «Роль» (Role) с ролью Platform Auditor.

Ассоциация с организациями и командами#

Членство пользователей LDAP в организациях и командах Astra Automation и их роли назначаются правилами сопоставления. В качестве триггеров правил используются группы LDAP, определяемые полями LDAP Group Type и LDAP Group Search, и атрибуты пользователя LDAP.

Например, для включения членов группы LDAP в команду Astra Automation создайте правило типа «Команда» (Team) с триггером «Группы» (Groups) и укажите целевые организацию, команду и роль. Для автоматического отзыва роли при утрате соответствия триггеру установите флаг Отозвать (Revoke).

RADIUS#

Предупреждение

Этот провайдер аутентификации считается устаревшим и в одной из следующих версий Astra Automation станет недоступным для применения.

SAML#

В Astra Automation поставщиком услуг является кластер Astra Automation, а поставщиком идентификационных данных – группа серверов SAML, предоставляющих услугу SSO.

В качестве идентификатора объекта поставщика услуг SAML необходимо указать базовый URL Astra Automation. Если для доступа к кластеру используется балансировщик нагрузки, необходимо указать его URL, например:

https://ac.example.com/

Требования к паре из открытого сертификата и закрытого ключа поставщика услуг приведены в секции Требования к сертификату и закрытому ключу.

Информацию об организации поставщика услуг SAML необходимо указывать в виде словаря, где ключи – названия локалей, а значения – вложенные словари с настройками.

Словарь с настройками может содержать следующие ключи:

  • url – URL кластера Astra Automation.

  • displayname – человекочитаемое название кластера Astra Automation.

  • name – внутреннее название кластера Astra Automation. Используется в качестве идентификатора на стороне провайдера SAML, позволяя ему отличать один кластер от другого.

Пример заполнения словаря:

{
  "ru-RU": {
    "url": "https://ac.example.com",
    "displayname": "Кластер Automation Controller",
    "name": "ac-cluster"
  }
}

Требования к сертификату и закрытому ключу#

Поставщик услуг SAML использует открытый сертификат и закрытый ключ для расшифровки утверждений и подписи запросов. Закрытый ключ (поле Закрытый ключ поставщика услуг SAML (SAML Service Provider Private Key)) должен удовлетворять следующим требованиям (проверено на Astra Automation 2.0):

  • Тип ключа – RSA, проверенные длины – 2048 и 4096 бит. Ключи ECDSA не поддерживаются: ключ с явными параметрами кривой отклоняется с сообщением ECDSA keys with explicit parameters are unsupported at this time, а ключ на именованной кривой приводит к внутренней ошибке сервера.

  • Ключ должен быть незашифрованным (без парольной фразы). Зашифрованный ключ отклоняется с сообщением Password was not given but private key is encrypted.

  • Поддерживаются контейнеры PKCS#8 (рекомендуется, маркер PRIVATE KEY в строках начала и конца содержимого) и PKCS#1 (маркер RSA PRIVATE KEY).

Открытый сертификат и закрытый ключ должны быть указаны с маркерами начала и конца содержимого. Пример для открытого сертификата:

-----BEGIN CERTIFICATE-----
AAAAA231jfdsalfkjkl........
-----END CERTIFICATE-----

Строки начала и конца закрытого ключа устроены так же: между -----BEGIN `` и ``----- (и соответственно между -----END `` и ``-----) записывается маркер контейнера – PRIVATE KEY для PKCS#8 или RSA PRIVATE KEY для PKCS#1.

Маркеры должны соответствовать фактическому формату данных ключа. Ключ, у которого маркеры заменены вручную без преобразования содержимого (например, содержимое PKCS#1 под маркерами PKCS#8), отклоняется с сообщением Unable to load as PEM data. Could not deserialize key data., в деталях которого упоминается ошибка разбора ASN.1.

Примечание

Команда openssl pkey -check допускает несоответствие маркеров содержимому, поэтому успешная проверка ключа средствами OpenSSL не гарантирует, что ключ будет принят платформой. Для приведения ключа к каноническому формату PKCS#8 необходимо использовать преобразование, а не замену маркеров:

openssl pkcs8 -topk8 -nocrypt -in key.pem -out key-pkcs8.pem

Для генерации самозаверенного сертификата и соответствующего закрытого ключа RSA можно использовать команду:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes

Для проверки целостности закрытого ключа (в контейнере PKCS#8 или PKCS#1) можно использовать команду:

openssl pkey -in key.pem -check -noout

Ожидаемый результат: Key is valid.

Атрибуты пользователей#

По умолчанию Astra Automation ожидает от провайдера SAML данные пользователя в следующем формате:

Username(urn:oid:0.9.2342.19200300.100.1.1)
Email(urn:oid:0.9.2342.19200300.100.1.3)
FirstName(urn:oid:2.5.4.42)
LastName(urn:oid:2.5.4.4)

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

  • User Permanent ID – атрибут утверждения SAML, содержащий уникальный идентификатор пользователя.

  • Username – атрибут утверждения SAML, содержащий название учетной записи пользователя.

  • User First Name – атрибут утверждения SAML, содержащий имя пользователя.

  • User Last Name – атрибут утверждения SAML, содержащий фамилию пользователя.

  • User Email – атрибут утверждения SAML, содержащий адрес электронной почты пользователя.

    Предупреждение

    Нельзя использовать один и тот же адрес электронной почты для нескольких учетных записей, в том числе для пользователей, созданных средствами Astra Automation.

Данные провайдера идентификации SAML задаются в следующих полях:

  • Entity ID – идентификатор объекта провайдера идентификации. Предоставляется провайдером SAML.

  • IdP Login URL – URL страницы аутентификации SAML. Astra Automation будет перенаправлять пользователей на эту страницу при аутентификации через SAML. Предоставляется провайдером SAML.

  • IdP Public Cert – сертификат провайдера идентификации SAML, с помощью которого Astra Automation проверяет подпись ответов. Указывается с маркерами начала и конца содержимого (-----BEGIN CERTIFICATE----- / -----END CERTIFICATE-----).

Описание остальных полей приведено в инструкции по созданию метода аутентификации.

Ассоциация с организациями, командами и ролями#

Членство пользователей SAML в организациях и командах Astra Automation, их роли и права суперпользователя назначаются правилами сопоставления. В качестве триггеров правил используются атрибуты утверждения SAML и группы из атрибута, указанного в поле Groups.

Например, для назначения роли в организации пользователям с определенным значением атрибута создайте правило типа «Организация» (Organization) с триггером «Атрибуты» (Attributes) и укажите целевые организацию и роль. Для автоматического отзыва роли при утрате соответствия триггеру установите флаг Отозвать (Revoke).

TACACS+#

Предупреждение

Этот провайдер аутентификации считается устаревшим и в одной из следующих версий Astra Automation станет недоступным для применения.

OIDC#

OpenID Connect (OIDC) используется для аутентификации пользователей Astra Automation через внешнего провайдера OpenID Connect. OIDC является надстройкой над OAuth 2.0 и добавляет механизм аутентификации пользователя с помощью токена идентификации (ID token) в формате JWT (JSON Web Token).

Схема работы OIDC#

Аутентификация через OIDC выполняется по следующей схеме:

  1. Пользователь выбирает вход через OIDC.

  2. Astra Automation перенаправляет пользователя на страницу входа внешнего провайдера OIDC.

  3. Пользователь проходит аутентификацию у провайдера.

  4. Провайдер OIDC возвращает пользователя в Astra Automation по URI перенаправления и передает код авторизации (authorization code).

  5. Astra Automation обращается к точке доступа токенов (token endpoint) провайдера и обменивает код авторизации на ID token и access token.

  6. При необходимости Astra Automation запрашивает дополнительные сведения о пользователе через точку доступа информации о пользователе (userinfo endpoint).

  7. Astra Automation проверяет ID token, получает сведения о пользователе и извлекает нужные значения по JSON-ключам.

  8. Astra Automation выполняет сопоставление пользователя с организациями и командами.

  9. Если проверка и сопоставление выполнены успешно, Astra Automation создает пользовательскую сессию.

Параметры провайдера OIDC#

Для настройки Generic OIDC достаточно указать URL провайдера OIDC (OIDC Provider URL), ключ и секрет OIDC – остальные точки доступа Astra Automation получает из метаданных провайдера автоматически. При необходимости URL точек доступа внешнего провайдера OIDC можно задать вручную:

  • URL-адрес авторизации (Authorization URL);

  • URL токена доступа (Access Token URL);

  • URI JWKS (JWKS URI);

  • URL информации о пользователе (Userinfo URL);

  • URL отзыва токена (Revoke Token URL), если провайдер поддерживает отзыв токенов.

В большинстве случаев эти адреса можно получить из метаданных провайдера OIDC:

https://<oidc_provider>/.well-known/openid-configuration

Для Keycloak в поле URL провайдера OIDC (OIDC Provider URL) укажите realm URL без пути /.well-known/openid-configuration, например:

https://keycloak.example.com/realms/myrealm

Platform Gateway самостоятельно добавляет путь /.well-known/openid-configuration и получает метаданные провайдера. Если указать полный URL метаданных, путь будет добавлен повторно, что приведет к ошибке 404 Not Found.

В метаданных провайдера OIDC используются следующие параметры:

Поле Astra Automation

Параметр метаданных

Назначение

URL провайдера OIDC (OIDC Provider URL)

issuer

Идентификатор провайдера OIDC

URL-адрес авторизации (Authorization URL)

authorization_endpoint

Перенаправление пользователя на страницу входа провайдера

URL токена доступа (Access Token URL)

token_endpoint

Обмен кода авторизации на токены

URI JWKS (JWKS URI)

jwks_uri

Получение открытых ключей для проверки подписи токенов

URL информации о пользователе (Userinfo URL)

userinfo_endpoint

Получение сведений о пользователе

URL отзыва токена (Revoke Token URL)

revocation_endpoint

Отзыв токена, если точка доступа поддерживается провайдером

URI перенаправления#

URI перенаправления (Redirect URI) – это адрес Astra Automation, на который внешний провайдер OIDC возвращает пользователя после успешной аутентификации. Этот адрес необходимо указать на стороне провайдера OIDC при создании клиентского приложения для Astra Automation.

Для Platform Gateway URI перенаправления имеет следующий формат:

https://<gateway>/api/gateway/social/complete/<slug>/

Здесь:

  • <gateway> – FQDN или IP-адрес Platform Gateway;

  • <slug> – относительный путь к методу аутентификации.

Slug формируется платформой автоматически как уникальный идентификатор метода аутентификации (UUID) и не зависит от значения поля Название (Name). Получить его можно из поля slug в ответе на запрос GET /api/gateway/v1/authenticators/.

Пример:

https://gateway.example.com/api/gateway/social/complete/21a93941-3e4b-4061-8466-ffecaba333ad/

Перед настройкой в производственной среде рекомендуется проверить фактическое значение Redirect URI. Для этого нажмите кнопку входа через OIDC и найдите параметр redirect_uri в запросе к провайдеру OIDC с помощью инструментов разработчика браузера. Именно это значение необходимо добавить в список разрешенных URI перенаправления на стороне провайдера OIDC.

Не указывайте в качестве URI перенаправления значение поля URL-адрес авторизации (Authorization URL).

Также не используйте в настройках Generic OIDC адрес https://<aa_host>/api/o/authorize/. Этот адрес относится к сценарию, в котором Astra Automation выступает OAuth2-провайдером для внешнего приложения.

Данные пользователя#

После успешной аутентификации провайдер OIDC передает в Astra Automation сведения о пользователе в ID token или в ответе на запрос к точке доступа UserInfo. Сведения передаются в виде пар ключей-значение в формате JSON.

Например, провайдер OIDC может передать следующие данные:

{
  "sub": "b6f4c2e8-9b8d-4c2a-9b6d-111111111111",
  "preferred_username": "oidc-test-user",
  "email": "oidc-test-user@example.com",
  "name": "OIDC Test User",
  "groups": [
    "admins",
    "devops"
  ]
}

В настройках Generic OIDC необходимо указать, какие JSON-ключи платформа Astra Automation должна использовать для идентификации пользователя и групп пользователей.

Поле Astra Automation

Назначение

Ключ ID (ID Key)

JSON-ключ с устойчивым идентификатором пользователя. Обычно используется sub.

Ключ имени пользователя (Username Key)

JSON-ключ, из которого Astra Automation получает имя учетной записи пользователя. Для Keycloak обычно используется preferred_username. Если пользователей нужно сопоставлять по email, укажите email.

Ключ групп (Groups Claim)

JSON-ключ, из которого Astra Automation получает список групп пользователя. Для Keycloak обычно используется groups, если у провайдера настроена передача групп в ключе groups. Если в поле указано значение Group, провайдер OIDC должен передавать группы пользователя в ключе Group.

Примечание

В полях Ключ ID (ID Key), Ключ имени пользователя (Username Key) и Ключ групп (Groups Claim) указывается не значение пользователя, а название ключа.

Например, если провайдер передает "preferred_username": "oidc-test-user", в поле Ключ имени пользователя (Username Key) укажите preferred_username, а не oidc-test-user.

Проверка токенов#

Для проверки ID token Astra Automation проверяет его подпись с помощью открытых ключей провайдера OIDC. Открытые ключи доступны по адресу, указанному в поле URI JWKS (JWKS URI).

ID token должен содержать claim aud, который идентифицирует клиентское приложение Astra Automation. Если claim отсутствует, проверка может завершиться ошибкой Token is missing the "aud" claim. Для Keycloak claim aud можно добавить с помощью mapper типа Audience.

Для Keycloak обычно используется алгоритм подписи:

RS256

Укажите это значение в поле Алгоритмы OIDC JWT (OIDC JWT Algorithm(s)), если метод Generic OIDC требует явного указания алгоритма.

Если при проверке входа появляется ошибка вида The token is not yet valid (iat), проверьте синхронизацию времени между узлом Astra Automation и узлом провайдера OIDC. Такая ошибка означает, что токен выпущен с временем, которое Astra Automation считает будущим.

В тестовой среде можно временно отключить проверку iat в поле Опции декодирования OIDC JWT (OIDC JWT Decode Options):

{
  "verify_iat": false
}

Предупреждение

Не используйте отключение проверки iat как постоянное решение в производственной среде. Правильный способ устранения ошибки – синхронизировать время между узлами Astra Automation и провайдера OIDC.

Сопоставление пользователей#

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

Параметр Ключ групп (Groups Claim) указывает, из какого JSON-ключа Astra Automation получает группы пользователя. Сам по себе он не назначает права пользователю. Для назначения прав необходимо настроить правило сопоставления.

Если имя пользователя, полученное от провайдера OIDC, уже используется другим методом аутентификации, Astra Automation создает отдельную учетную запись с автоматически сформированным суффиксом. Например, если локальная учетная запись admin уже существует, пользователь OIDC с именем admin может быть создан как admin2d220bc5dd834848.

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

Поле Автоматически мигрировать пользователей из (Auto migrate users from) можно использовать при переходе с ранее настроенного метода аутентификации.

Миграция может завершиться без ошибки, но результат зависит от идентификатора пользователя. В проверенных сценариях использование email и preferred_username привело к созданию отдельной учетной записи или имени с суффиксом.

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

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

Пошаговый пример настройки SSO с помощью OIDC см. в инструкции.