Ключевые понятия
Реалм (realm)
Механизм объединения пользователей в группы. Механизм реалмов позволяет в рамках одного решения RooX UIDM организовать обслуживание разных категорий пользователей с разными сценариями, источниками данных и приложений. Пользователи в разных реалмах могут иметь одинаковые логин и идентификаторы, при этом они будут являться разными пользователями с точки зрения системы. В частности, для каждого реалма независимо настраиваются:
-
источники учетных записей пользователей, в т.ч. со своей атрибутной моделью профиля пользователя
-
поддерживаемые способы аутентификации
-
сценарии аутентификации
-
приложения, в которые выполняет аутентификацию пользователь
-
политики авторизации
Примеры
Реалм Customers
-
Включает пользователей-физических лиц.
-
Данные пользователей хранятся в БД сервера RooX UIDM
-
Для пользователей поддерживается вход по логину-паролю, по OTP, через соц.сети
-
Сценарии предполагают вход одним из перечисленных способов + опциональный ввод OTP в соответствии с настройками пользователя.
-
Пользователи могут выполнять вход в приложения для физических лиц (личный кабинет физического лица, сервисы развлекательного контента)
Реалм B2B
-
Включает пользователей, действующих от лица юридических лиц.
-
Данные пользователей хранятся в БД сервера RooX UIDM, а также в интегрированных сервисах, где хранятся унаследованные учетные записи.
-
Для пользователей поддерживается вход по логину-паролю, по унаследованной учетной записи прикладной платформы, через систему ЕСИА
-
Сценарии предполагают вход одним из перечисленных способов + обязательную регистрацию единой учетной записи, если выполнялся вход по унаследованной учетной записи продуктовой платформы.
-
Пользователи могут выполнять вход в приложения для юридически лиц (личный кабинет юридического лица при наличии соответствующего уровня пользователя, корпоративные сервисы)
Реалм employee
-
Включает пользователей - сотрудников организации.
-
Данные пользователей хранятся в Active Directory организации.
-
Для пользователей поддерживается вход по доменному логину-паролю, а также через Kerberos
-
Сценарии предполагают вход только по доменной учетной записи.
-
Пользователи могут выполнять вход только во внутренние приложения организации, размещенные в интрасети.
Клеймы (claims)
Клеймы (claims)
Клейм - это утверждение об аутентифицированном пользователе или его сессии или окружении, в котором он работает.
Клеймы записываются сервером RooX UIDM в токен во время аутентификации и хранятся там до окончания времени жизни токена.
RooX UIDM забирает клеймы из следующих провайдеров:
-
сессия предлогина (вебфлоу)
-
информация об устройстве пользователя (запоминается информация из первого шага сценария в случае многошаговых сценариев): User-Agent, геолокация, …
-
профиль пользователя, загруженный из RooX IdRepo
-
профиль пользователя, загруженный из внешнего IdRepo, если применимо
-
профиль пользователя, загруженный из соцсети или IDP, если применимо
Примеры
-
идентификатор пользователя
-
использованный логин
-
время аутентификации
-
IP адрес, с которого произошла аутентификация
-
номер телефона для OTP
-
ФИО
Получение доступа к клеймам
Серверное приложение бизнес-логики может получить клеймы из ответа API /tokeninfo. Некоторые клеймы являются встроенными и отдаются всегда, а некоторые отдаются только при наличии у приложения заданного scope. В таблице ниже указано, какие скоупы требуются для каких клеймов.
Мобильное приложение бизнес-логики может получить клеймы через Mobile SDK (которое внутри в свою очередь получает клеймы из JWT Identity Token).
Таблица клеймов
Название | Описание | Тип данных | Пример |
---|---|---|---|
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), а RooX UIDM обеспечивает уникальность только с префиксом, так как в RooX UIDM могут быть подключены множественные источники учетных записей, то вводится отдельный claim "ext_sub", который разрешается испоьзовать только при уверенности, что в конкретной инсталляции пересечений быть не может
-
login_password, apitokens. Список будет расширен
-
роли пользователя в организации при использовании мультиорганизационной модели сюда не входят
Название | Описание | Тип данных | Пример |
---|---|---|---|
externalIdpToken |
Токен внешней системы, если использовалась внешняя система |
string |
"xjhl1h1hgdui.1j23loidsd" |
preferred_username |
Логин пользователя (не идентификатор!) |
string |
"username1" |
name |
ФИО пользователя (формат определяется внешней системой) |
string |
"Иванов Иван Иванович" |
Уровни авторизации (auth_level)
Уровень авторизации - числовое значение, определяющее множество операций, доступных защищаемому сервису для выполнения от лица пользователя. Операция защищаемого сервиса может иметь минимальный требуемый уровень авторизации и выполняться только если текущий уровень авторизации пользователя больше или равен минимальной.