Ключевые понятия

Реалм (realm)

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

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

Примеры

Реалм Customers

Включает пользователей-физических лиц.
Данные пользователей хранятся в БД сервера UIDM
Для пользователей поддерживается вход по логину-паролю, по OTP, через соц.сети
Сценарии предполагают вход одним из перечисленных способов + опциональный ввод OTP в соответствии с настройками пользователя.
Пользователи могут выполнять вход в приложения для физических лиц (личный кабинет физического лица, сервисы развлекательного контента)

Реалм B2B

Включает пользователей, действующих от лица юридических лиц.
Данные пользователей хранятся в БД сервера UIDM, а также в интегрированных сервисах, где хранятся унаследованные учетные записи.
Для пользователей поддерживается вход по логину-паролю, по унаследованной учетной записи прикладной платформы, через систему ЕСИА
Сценарии предполагают вход одним из перечисленных способов + обязательную регистрацию единой учетной записи, если выполнялся вход по унаследованной учетной записи продуктовой платформы.
Пользователи могут выполнять вход в приложения для юридически лиц (личный кабинет юридического лица при наличии соответствующего уровня пользователя, корпоративные сервисы)

Реалм employee

Включает пользователей - сотрудников организации.
Данные пользователей хранятся в Active Directory организации.
Для пользователей поддерживается вход по доменному логину-паролю, а также через Kerberos
Сценарии предполагают вход только по доменной учетной записи.
Пользователи могут выполнять вход только во внутренние приложения организации, размещенные в интрасети.

Клеймы (claims)

Клейм - это утверждение об аутентифицированном пользователе или его сессии или окружении, в котором он работает.

Клеймы записываются сервером UIDM в токен во время аутентификации и хранятся там до окончания времени жизни токена.

UIDM забирает клеймы из следующих провайдеров:

сессия предлогина (вебфлоу)
информация об устройстве пользователя (запоминается информация из первого шага сценария в случае многошаговых сценариев): User-Agent, геолокация, …
профиль пользователя, загруженный из RooX IdRepo
профиль пользователя, загруженный из внешнего IdRepo, если применимо
профиль пользователя, загруженный из соцсети или IDP, если применимо

Примеры

идентификатор пользователя
использованный логин
время аутентификации
IP адрес, с которого произошла аутентификация
номер телефона для OTP
ФИО

Получение доступа к клеймам

Серверное приложение бизнес-логики может получить клеймы из ответа API /tokeninfo. Некоторые клеймы являются встроенными и отдаются всегда, а некоторые отдаются только при наличии у приложения заданного scope. В таблице ниже указано, какие скоупы требуются для каких клеймов.

Мобильное приложение бизнес-логики может получить клеймы через Mobile SDK (которое внутри в свою очередь получает клеймы из JWT Identity Token).

Таблица клеймов

Таблица 1. Встроенные клеймы, возвращаются вне зависимости от запрошенного и разрешенного scope
Название	Описание	Тип данных	Пример
sub	Идентификатор принципала, уникальное	string с префиксом имени системы	sso___123123123
ext_sub	Идентификатор принципала без префикса (1)	string	123123123
jti	Идентификатор токена доступа	string, uuid	54732921-86cc-49e7-af67-19f61b453ad1
auth_time	Дата и время аутентификации	integer, unixtime	1594634014
authType	Использованный способ аутентификации (2)	string, enum	login_password
roles	Список ролей пользователя (3)	string array	['CUSTOMER','VIP']
auth_level	Уровень аутентификации, значение зависит от настроек и способа	string, но внутри integer	"5"

поскольку протокол требует уникальности sub (OIDC 5.7. Claim Stability and Uniqueness), а UIDM обеспечивает уникальность только с префиксом, так как в UIDM могут быть подключены множественные источники учетных записей, то вводится отдельный claim "ext_sub", который разрешается испоьзовать только при уверенности, что в конкретной инсталляции пересечений быть не может
login_password, apitokens. Список будет расширен
роли пользователя в организации при использовании мультиорганизационной модели сюда не входят

Таблица 2. Клеймы, доступ к которым определяется разрешениями сервиса
Название	Описание	Тип данных	Пример
externalIdpToken	Токен внешней системы, если использовалась внешняя система	string	"xjhl1h1hgdui.1j23loidsd"
preferred_username	Логин пользователя (не идентификатор!)	string	"username1"
name	ФИО пользователя (формат определяется внешней системой)	string	"Иванов Иван Иванович"

Уровни авторизации (auth_level)

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