Управление настройками приложений OAuth2/OIDC

Содержание

Управление настройками приложений OAuth2/OIDC#

Данный раздел описывает порядок управления настройками OAuth2/OIDC-клиентов в установленной системе.

Общая схема настройки#

В терминах OAuth2 и OpenID Connect сервис roox-sso выполняет роль Authorization Server и OpenID Provider. Он использует настройки клиентов, реалмов, scopes и claims при обработке OAuth2/OIDC-запросов.

Основные файлы настройки в установленной системе:

Файл	Назначение
`/usr/share/tomcat/clients.properties`	Настройки OAuth2/OIDC-клиентов
`/usr/share/tomcat/oidc.properties`	Настройки OpenID Connect, claims и discovery metadata
`/usr/share/tomcat/realms.properties`	Настройки реалмов и общие параметры OAuth2/OIDC
`/usr/share/tomcat/config.xml`	Список подключаемых файлов настроек и порядок их применения

Если один и тот же параметр указан в нескольких подключенных файлах, сервис roox-sso применяет значение из файла с большим приоритетом, согласно /usr/share/tomcat/config.xml. Перед изменением следует проверить, не переопределен ли параметр в другом файле.

После изменения настроек необходимо

Перезапустить сервис командой:

sudo systemctl restart roox-sso

Проверить запуск сервиса по журналу:

/var/log/roox-sso/roox-sso.log

Формат ключей OAuth2/OIDC-клиентов#

Настройки клиента задаются в файле /usr/share/tomcat/clients.properties ключами вида:

com.rooxteam.sso.<realm>.oauth2.sp.<clientId>.<parameter>=<value>

Где:

<realm> — реалм, например employee или customer;
<{clientId> — идентификатор OAuth2/OIDC-клиента;
<parameter> — параметр клиента.

Для списковых параметров значения перечисляются через запятую без пробелов:

com.rooxteam.sso.employee.oauth2.sp.my_client.defaultScopes=openid,profile,email
com.rooxteam.sso.employee.oauth2.sp.my_client.redirectionURIs=https://app.example.org/callback,https://app.example.org/alt-callback

Типовые операции администратора#

В этом подразделе приведены действия администратора. Подробные форматы и допустимые значения параметров описаны в подразделе Справочник параметров.

Изменение redirect URI клиента#

Для изменения redirect URI клиента необходимо:

Найти клиента в файле /usr/share/tomcat/clients.properties по clientId.
Изменить параметр redirectionURIs.
Если клиент вызывает endpoints roox-sso из браузера через fetch/XHR и для этих запросов требуется CORS, проверить также agentOrigins.
Перезапустить сервис roox-sso.
Проверить авторизацию через клиента.

Пример:

com.rooxteam.sso.employee.oauth2.sp.my_client.redirectionURIs=https://app.example.org/callback,https://app.example.org/alt-callback
com.rooxteam.sso.employee.oauth2.sp.my_client.agentOrigins=https://app.example.org

Изменение client secret#

Для изменения client secret необходимо:

Согласовать новый client_secret с владельцем клиента.
В файле /usr/share/tomcat/clients.properties изменить userpassword у нужного clientId.
Обновить секрет на стороне клиента.
Перезапустить сервис roox-sso.
Проверить авторизацию или получение токена.

Пример:

com.rooxteam.sso.employee.oauth2.sp.my_client.userpassword={argon2}$argon2id$...

Изменение набора scopes и claims для клиента#

Для изменения набора scopes и claims для клиента необходимо:

Найти клиента в файле /usr/share/tomcat/clients.properties.
Изменить список defaultScopes, если нужно изменить scopes, выдаваемые клиенту без явного scope в запросе.
Изменить список scopes, если нужно изменить scopes, которые клиент может запросить явно.
Для сервисного клиента добавить или изменить clientClaims, если нужны фиксированные claims в access token, выдаваемых по client_credentials, или во внутренних служебных access token.
Перезапустить сервис roox-sso.
Проверить состав токена или ответ userinfo.

Пример:

com.rooxteam.sso.employee.oauth2.sp.my_client.defaultScopes=openid,profile,email
com.rooxteam.sso.employee.oauth2.sp.my_client.scopes=openid,profile,email,roles
com.rooxteam.sso.employee.oauth2.sp.my_client.clientClaims=organization_id=<organization-id>

Изменение маппинга атрибутов профиля UIDM на claims#

Для изменения маппинга атрибутов профиля UIDM на claims необходимо:

Найти claim в файле /usr/share/tomcat/oidc.properties.
Изменить property, если claim должен брать значение из другого атрибута профиля UIDM.
При необходимости изменить scope, если claim должен выдаваться для другого набора scopes.
Перезапустить сервис roox-sso.
Проверить выдачу claim через id_token или userinfo.

Пример:

com.rooxteam.sso.claims.email=scope=openid profile email,property=contactEmail,source=identity

Справочник путей к конфигурационным файлам#

Файл настройки на VM	Назначение	Ответственный сервис	Действие после изменения
`/usr/share/tomcat/clients.properties`	Настройки OAuth2/OIDC-клиентов	`roox-sso`	Перезапуск `roox-sso`
`/usr/share/tomcat/oidc.properties`	Настройки OpenID Connect, claims и discovery metadata	`roox-sso`	Перезапуск `roox-sso`
`/usr/share/tomcat/realms.properties`	Настройки реалмов и общие параметры OAuth2/OIDC	`roox-sso`	Перезапуск `roox-sso`
`/usr/share/tomcat/config.xml`	Список подключаемых файлов настроек и порядок их применения	`roox-sso`	Перезапуск `roox-sso`, если изменен состав или порядок файлов

Справочник параметров#

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

Параметры OAuth2/OIDC-клиента#

Параметр	Значение по умолчанию	Пример	Описание
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.enabled`	`false`	`true	Включает клиента. Допустимые значения: `true`, `false`
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.clientType`	`CONFIDENTIAL`	`PUBLIC`	Тип клиента OAuth 2.0. Допустимые значения см. в подразделе Тип клиента
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.userpassword`	нет	`{argon2}$argon2id$...`	Хранимое значение `client_secret` клиента OAuth 2.0 Форматы значения см. в подразделе Форматы client secret
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.grantTypes`	нет	`authorization_code,refresh_token`	Grant types, разрешенные клиенту. Связано с OAuth 2.0 `grant_type` и metadata- параметром `grant_types`. Допустимые значения см. в подразделе Grant types
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.redirectionURIs`	пустой список	`https://app.example.org/callback`	Зарегистрированные `redirect_uri` клиента OAuth 2.0. Правила проверки см. в подразделе Redirect URI
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.agentOrigins`	пустой список	`https://app.example.org`	Разрешенные origins для CORS-запросов к сервису `roox-sso`. Правила применения см. в подразделе Agent origins
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.defaultScopes`	пустой список	`openid,profile,email`	Scopes, выдаваемые клиенту по умолчанию. Связь со `scopes` см. в подразделе client_scopes
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.scopes`	пустой список	`openid,profile,email,roles`	Scopes, которые клиент может запросить явно
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.sunIdentityServerDeviceKeyValue`	пустой список	`ROLE=ROLE_PROVISION,bss=bis_`	client_attrebutes в формате `key=value`
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.roles`	пустой список	`ROLE_SYSTEM,ROLE_PROVISION`	Роли клиента. Объединяются с ролями из `sunIdentityServerDeviceKeyValue`. См. подраздел client_attrebutes
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.clientClaims`	пустой список	`organization_id=12345`	Фиксированные claims сервисного клиента. Формат см. в подразделе client_claims
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.audience`	пустой список	`arm_cc_back`	Значения audience (`aud`) для токена
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.pkceRequired`	`false`	`true`	Требует PKCE для клиента. Допустимые значения: `true`, `false`
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.enableEventNotifications`	`false`	`true`	Включает отправку уведомлений о событиях, связанных с клиентом. Подробности см. в подразделе client_event_notifications
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.access_token.ttl`	`3600`	`900`	Время жизни access token в секундах. Порядок выбора значения см. в подразделе tokens_TTL
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.refresh_token.ttl`	`3600`	`36060`	Время жизни refresh token в секундах
`com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.authorization_code.ttl`	`30`	`60`	Время жизни authorization code в секундах

Тип клиента#

Параметр clientType задает тип клиента в терминах OAuth 2.0 Client Types.

Значение	Описание
`CONFIDENTIAL`	Confidential client: клиент способен сохранять конфиденциальность своих credentials, например серверное приложение с ограниченным доступом к `client_secret`
`PUBLIC`	Public client: клиент не способен сохранять конфиденциальность credentials, например приложение, выполняющееся на устройстве пользователя или в браузере

Если значение не задано, используется CONFIDENTIAL. Значение CONFIDENTIAL проверяется без учета регистра. Любое другое значение обрабатывается как PUBLIC, поэтому в настройках необходимо использовать только явные значения CONFIDENTIAL или PUBLIC.

Форматы client secret#

Параметр userpassword хранит секрет OAuth2/OIDC-клиента. Значение может быть задано в формате:

{scheme}<encoded-secret>

Если префикс {scheme} отсутствует, значение обрабатывается как plaintext.

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

Схема	Пример	Комментарий
`argon2`	`{argon2}$argon2id$...`	Рекомендуемый вариант для новых секретов. Пример команды см. в приложении Приложение A. Генерация хэша client secret
`bcrypt`	`{bcrypt}$2a$...`	Поддерживаемый хэшированный формат. Пример команды см. в приложении Приложение A. Генерация хэша client secret
`pbkdf2`	`{pbkdf2}...`	Поддерживаемый хэшированный формат для системных приложений. Пример команды см. в приложении Приложение A. Генерация хэша client secret
`sha256b64`	`{sha256b64}...`	Совместимый формат; используется только при необходимости совместимости
`md5`	`{md5}...`	Legacy-формат; не используется для новых секретов
`aes`	`{aes}...`	Совместимый обратимый формат; используется только если это принято в конкретной поставке
plaintex`t	`{plaintext}<secret>` или `<secret>`	Технически поддерживается, но не рекомендуется, так как хранит секрет в открытом виде

Схемы, предназначенные для состояний пользовательского пароля, например resetrequired или password_authn_prohibited, не следует использовать для client_secret: клиент не сможет пройти аутентификацию. Если указана неизвестная схема, клиент также не сможет пройти аутентификацию.

Grant types#

Параметр grantTypes задает список grant types, которые разрешены клиенту. В терминах OAuth 2.0 grant type определяет способ получения токена. Как metadata-параметр клиента список grant types описан в RFC 7591, Section 2 <https://www.rfc-editor.org/rfc/rfc7591#section-2>`_.

Если grantTypes не задан, сервис roox-sso не выполняет явную проверку grant type для клиента. Такое поведение сложнее контролировать и диагностировать, поэтому для эксплуатационных конфигураций рекомендуется всегда задавать grantTypes явно.

Реализация сервиса roox-sso поддерживает следующие значения для token endpoint:

Сценарий	Значение `grantTypes`	Стандарт
Authorization Code	`authorization_code`	RFC 6749, Section 4.1
Refresh Token	`refresh_token`	RFC 6749, Section 6
Client Credentials	`client_credentials`	RFC 6749, Section 4.4
Token Exchange	`urn:ietf:params:oauth:grant-type:token-exchange`	RFC 8693, Section 2.1
M2M (ПУИД)	`urn:roox:params:oauth:grant-type:m2m`	Расширение ПУИД
M2M Authorization Code (ПУИД)	`urn:roox:params:oauth:grant-type:m2m-authorization-code`	Расширение ПУИД
M2M Flow (ПУИД)	`urn:roox:params:oauth:grant-type:m2m-flow`	Расширение ПУИД

M2M grant types — расширение ПУИД. Их используют сценарии, где клиентское приложение реализует собственный UX аутентификации и передает параметры процесса на token endpoint, вместо перенаправления пользователя на authorization endpoint.

Redirect URI#

В redirectionURIs необходимо указать все допустимые callback URI клиента. В терминах OAuth 2.0 это redirection endpoint URI. Сервис roox-sso принимает redirect_uri из OAuth2/OIDC-запроса, если он совпадает с одним из значений списка после нормализации URI.

При проверке:

учитываются путь, query-параметры и нестандартный порт;
фрагмент URI (#...) запрещен;
регистр схемы и имени хоста не учитывается;
стандартные порты 80 для HTTP и 443 для HTTPS нормализуются.

Agent origins#

Параметр agentOrigins используется при CORS-проверках для запросов, которые браузер отправляет напрямую на endpoints сервиса roox-sso с HTTP-заголовком Origin. Это актуально для SPA/PWA и других клиентов, которые вызывают сервис roox-sso из браузера через fetch/XHR.

Для обычного OAuth2/OIDC redirect-сценария, где браузер переходит на authorization endpoint через навигацию страницы, agentOrigins сам по себе не требуется: такой переход не является CORS-запросом.

Сервис roox-sso разрешает CORS-запрос, если Origin совпадает с одним из значений agentOrigins хотя бы у одного OAuth2/OIDC-клиента включенного реалма. При сравнении origin нормализуется: если порт не указан, для HTTP используется 80, для HTTPS — 443; сравнение выполняется без учета регистра.

Пример:

com.rooxteam.sso.employee.oauth2.sp.my_spa_client.agentOrigins=https://app.example.org

Scopes клиента

Параметры defaultScopes и scopes работают совместно. Для OAuth 2.0 параметр scope определен в RFC 6749, Section 3.3, а стандартные OIDC scope values для запроса claims описаны в OpenID Connect Core, Section 5.4.

если запрос не содержит scope, сервис roox-sso использует defaultScopes;
если запрос содержит scope, сервис roox-sso берет пересечение запрошенных scopes со списком scopes и дополнительно добавляет defaultScopes;
если defaultScopes содержит claim или scope, он будет добавлен в результирующий набор даже при явном scope в запросе.

Рекомендуется использовать defaultScopes для обязательного набора scopes клиента, а scopes — для набора scopes, которые клиент может запросить дополнительно.

Атрибуты клиента

Параметр sunIdentityServerDeviceKeyValue хранит дополнительные атрибуты клиента в формате key=value.

Типичные атрибуты:

Атрибут	Назначение
`ROLE=<role>`	Роль клиента. Роли из `ROLE=...` объединяются со списком `roles` и попадают в роли access token для сервисных сценариев
`bss=<prefix>`	BSS-префикс клиента. Может использоваться серверными интеграциями при проверке Basic Auth и внутренних служебных токенов

Пример:

com.rooxteam.sso.employee.oauth2.sp.my_client.sunIdentityServerDeviceKeyValue=ROLE=ROLE_PROVISION,bss=bis_
com.rooxteam.sso.employee.oauth2.sp.my_client.roles=ROLE_SYSTEM

Для новых ролей можно использовать отдельный параметр roles, но ROLE=... в sunIdentityServerDeviceKeyValue продолжает учитываться существующими проверками и интеграциями. Поэтому при изменении уже настроенного клиента не следует удалять sunIdentityServerDeviceKeyValue, если неизвестно, какие компоненты используют его атрибуты.

Client claims

Параметр clientClaims добавляет фиксированные claims для сервисного клиента. Он применяется при выпуске access token по client_credentials и при создании внутренних служебных access token через механизм self-authentication ПУИД.

Внутренний служебный токен в этом контексте — это токен, который сервис roox-sso создает для обращения одного серверного компонента продукта к другому от имени настроенного клиента. Это не отдельный OAuth2 grant type и не синоним любого токена, полученного по client_credentials.

Формат элемента:

claim=value

Несколько claims перечисляются через запятую:

com.rooxteam.sso.employee.oauth2.sp.my_client.clientClaims=organization_id=12345,system=true

Если элемент не содержит =, он игнорируется.

Уведомления о событиях клиента

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

Если значение false, события с этим clientId не отправляются через механизм уведомлений. Описание механизма уведомлений и его настройка выходят за рамки данного раздела.

TTL токенов

Для authorization_code, access_token и refresh_token поддерживается настройка времени жизни в секундах. Самое точное значение имеет приоритет над более общими значениями.

Порядок выбора:

com.rooxteam.sso.{realm}.oauth2.sp.{clientId}.<token>.ttl
com.rooxteam.sso.{realm}.oauth2.sp.<token>.ttl
com.rooxteam.sso.oauth2.sp.<token>.ttl
com.rooxteam.sso.{realm}.oauth2.idp.<token>.ttl
com.rooxteam.sso.oauth2.idp.<token>.ttl
встроенное значение по умолчанию

Где <token> — authorization_code, access_token или refresh_token.

Встроенные значения по умолчанию:

Token	Значение
`authorization_code`	`30` секунд
`access_token`	`3600` секунд
`refresh_token`	`3600` секунд

OIDC-параметры#

Параметр	Значение по умолчанию	Пример	Описание
`com.rooxteam.sso.id_token.claims`	`cn,preferred_username`	`preferred_username,roles,email`	Дополнительные claims, которые нужно включать в `id_token` помимо обязательных claims ID Token. См. OpenID Connect Core, Section 2
`com.rooxteam.uidm.userinfo.claims_whitelist`	нет	`openid,profile,email`	Claims, которые разрешено отдавать через `userinfo` и пользовательский endpoint профиля. См. OpenID Connect Core, Section 5.3
`com.rooxteam.sso.claims.{claim}`	нет	`scope=openid profile email,property=contactEmail,source=identity`	Маппинг внешнего claim на атрибут профиля UIDM. Стандартные claims описаны в OpenID Connect Core, Section 5.1. Формат см. в разделе Mapping_claims
`com.rooxteam.sso.well-known.openid-configuration.claims_supported`	нет	`openid,profile,email`	Список claims, публикуемый в OIDC discovery metadata. См. OpenID Connect Discovery, Section 3
`com.rooxteam.sso.well-known.openid-configuration.scopes_supported`	нет	`openid,profile,email`	Список scopes, публикуемый в OIDC discovery metadata. См. OpenID Connect Discovery, Section 3
`com.rooxteam.sso.{realm}.oauth2.idp.client_auth_methods_supported`	нет	`client_secret_basic,client_secret_post`	Методы аутентификации клиентов, публикуемые для реалма в OIDC discovery metadata. См. OpenID Connect Discovery, Section 3

Claims в ID Token

Параметр com.rooxteam.sso.id_token.claims задает имена claims, которые сервис roox-sso должен добавить в id_token сверх обязательного состава ID Token (iss, sub, aud, exp, iat и др.).

Чтобы claim появился в id_token, недостаточно добавить его имя только в com.rooxteam.sso.id_token.claims: этот claim также должен быть сформирован для токена. Для пользовательских claims необходимо проверить маппинг com.rooxteam.sso.claims.{claim} и scopes клиента; для фиксированных claims сервисного клиента — clientClaims.

Маппинг claims

Маппинг claims задается в файле /usr/share/tomcat/oidc.properties параметрами вида:

com.rooxteam.sso.claims.{claim}=scope=<scopes>,property=<uidm-attribute>,source=identity

Формат значения:

Элемент	Описание
`scope=<scopes>`	Scopes, при наличии которых claim может быть выдан. Scopes внутри значения разделяются пробелами
`property=<uidm-attribute>`	Атрибут профиля пользователя UIDM, из которого берется значение claim
`source=identity`	Источник значения claim — профиль пользователя

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

Проверка получения токена системным клиентом#

Для проверки получения токена системным клиентом необходимо выполнить команду:

  curl -X POST https://<sso-host>/sso/realms/<realm>/as/oauth2/idp/access_token \
   -d "grant_type=client_credentials" \
   -d "client_id=<clientId>" \
   -d "client_secret=<secret>"


Проверка сведений о токене
-------------------------------

Для проверки сведений о токене необходимо выполнить команду:

curl -X POST https://<sso-host>/sso/realms/<realm>/as/oauth2/idp/tokeninfo \
 -d "access_token=<access_token>"

Проверка OIDC discovery#

Для проверки OIDC discovery необходимо выполнить команду:

curl https://<sso-host>/sso/realms/<realm>/as/oauth2/idp/.well-known/openid-configuration

Актуальные пути OAuth2/OIDC endpoints:

Endpoint	Метод	Путь
Получение токена	`POST`	`/sso/realms/{realm}/as/oauth2/idp/access_token`
Авторизация пользователя	`GET`	`/sso/realms/{realm}/as/oauth2/idp/authorize`
Отзыв токена	`POST`	`/sso/realms/{realm}/as/oauth2/idp/revoke`
Проверка токена	`GET`/`POST`	`/sso/realms/{realm}/as/oauth2/idp/tokeninfo`
Информация о пользователе	`GET`/`POST`	`/sso/realms/{realm}/as/oauth2/idp/userinfo`
Публичные ключи	`GET`	`/sso/realms/{realm}/as/oauth2/idp/jwks.json`

Приложение A. Генерация хэша client secret#

Команды ниже выводят готовое значение для параметра userpassword вместе с префиксом схемы. Не следует передавать секрет прямо в аргументах команды: так он может попасть в историю shell или список процессов. Рекомендуется использовать интерактивный ввод или переменные окружения с последующей очисткой.

Примеры используют параметры по умолчанию ПУИД:

Схема	Параметры по умолчанию
`argon2`	Argon2id, `memory=19456 KiB`, `iterations=2`, `parallelism=1`, длина хэша `32` байта
`bcrypt`	Cost `10`
`pbkdf2`	`PBKDF2WithHmacSHA256`, соль `16` байт, `iterations=1`, pepper пустой.

Если в поставке изменены параметры com.rooxteam.sso.argon2.*, com.rooxteam.sso.bcrypt.strength или com.rooxteam.sso.pbkdf2.*, следует использовать значения конкретной среды.

Argon2#

Требуется CLI-утилита argon2.

read -rsp 'client_secret: ' CLIENT_SECRET; echo
SALT="$(openssl rand -base64 12)"
HASH="$(printf '%s' "$CLIENT_SECRET" | argon2 "$SALT" -id -t 2 -k 19456 -p 1 -l 32 -e)"
printf '{argon2}%s\n' "$HASH"
unset CLIENT_SECRET

Если версия argon2 не поддерживает параметр -k, рекомендуется использовать параметр памяти, доступный в имеющейся версии утилиты. Итоговая строка Argon2 содержит параметры хэширования внутри значения $argon2id$....

bcrypt#

Требуется утилита htpasswd из пакета apache2-utils или httpd-tools.

read -rsp 'client_secret: ' CLIENT_SECRET; echo
HASH="$(printf '%s\n' "$CLIENT_SECRET" | htpasswd -niB -C 10 client | cut -d: -f2)"
printf '{bcrypt}%s\n' "$HASH"
unset CLIENT_SECRET

htpasswd может вывести bcrypt-хэш с префиксом $2y$ , $2a$ или $2b$ ; эти варианты принимаются при проверке секрета.

PBKDF2#

Требуется python3 из стандартной поставки Linux-дистрибутива. Команда формирует формат, который ожидает ПУИД: шестнадцатеричное представление salt || derived_key с префиксом {pbkdf2}.

python3 - <<'PY'
import getpass
import hashlib
import os

secret = getpass.getpass('client_secret: ').encode('utf-8')
salt = os.urandom(16)
derived_key = hashlib.pbkdf2_hmac('sha256', secret, salt, 1, dklen=32)
print('{pbkdf2}' + (salt + derived_key).hex())
PY

Если в среде задан непустой pepper или изменены iterations/ algorithm, необходимо адаптировать команду под значения com.rooxteam.sso.pbkdf2.pepper, com.rooxteam.sso.pbkdf2.iterations и com.rooxteam.sso.pbkdf2.algorithm.

Особенности Платформы Astra Cloud#

Этот подраздел содержит настройки, характерные для Платформы Astra Cloud.

Настроенные клиенты проекта#

Ниже перечислены OAuth2/OIDC-клиенты из файла /usr/share/tomcat/clients.properties для реалма employee.

Client ID	Тип	Grant types	Назначение
`provision_e`	`CONFIDENTIAL`	не задано явно	Сервисный клиент provisioning-сценариев
`arm_cc`	`CONFIDENTIAL`	`authorization_code`, `refresh_token`	Клиент административной панели ПУИД
`arm_cc_back`	`CONFIDENTIAL`	`client_credentials`, `urn:ietf:params:oauth:grant-type:token-exchange`	Backend-клиент административной панели и системных операций
`sys_sync`	`CONFIDENTIAL`	`client_credentials`	Сервисный клиент синхронизации
`sys_aal_e`	`CONFIDENTIAL`	`client_credentials`, `urn:roox:params:oauth:grant-type:m2m`	Сервисный клиент для межсервисной авторизации в реалме `employee`
`selfservice_e`	`CONFIDENTIAL`	`authorization_code`, `refresh_token`, `urn:roox:params:oauth:grant-type:m2m`	Клиент личного кабинета самообслуживания сотрудников
`aic-bm`	`CONFIDENTIAL`	`authorization_code`	OIDC-интеграция с биллинговым менеджером AIC
`amon`	`CONFIDENTIAL`	`authorization_code`	OIDC-интеграция с Astra Monitoring
`brest`	`CONFIDENTIAL`	`authorization_code`	OIDC-интеграция с сервисом Brest
`apos`	`CONFIDENTIAL`	`authorization_code`, `refresh_token`	Серверный клиент APOS
`apos_web`	`PUBLIC`	`authorization_code`, `refresh_token`	Браузерный клиент APOS
`iaas`	`CONFIDENTIAL`	`client_credentials`	Сервисный клиент IaaS
`grafana`	`CONFIDENTIAL`	`authorization_code`	OIDC-интеграция Grafana

Проектный маппинг claims#

Claim	Атрибут профиля UIDM	Scopes
`email`	`contactEmail`	`saml`, `wsfed`, `email`
`name`	`displayName`	`saml`, `profile`, `wsfed`
`given_name`	`givenname`	`saml`, `wsfed`
`middle_name`	`middleName	`saml`, `wsfed`
`family_name`	`sn`	`saml`, `wsfed`
`phone_number`	`contactPhone`	`saml`, `wsfed`

Проектные OIDC-настройки#

Состав id_token:

com.rooxteam.sso.id_token.claims=preferred_username,roles,sn,givenname,exp,iat,sub,middleName,displayName,email

Whitelist для userinfo:

com.rooxteam.uidm.userinfo.claims_whitelist=address,phone,openid,profile,email,displayName

Для добавления нового клиента в Платформу Astra Cloud необходимо использовать структуру ключей из раздела Формат ключей OAuth2/OIDC-клиентов, задать необходимые grant types, redirect URI, scopes и секрет, затем перезапустить сервис roox-sso.

Версии

Управление настройками приложений OAuth2/OIDC

Содержание

Управление настройками приложений OAuth2/OIDC#

Общая схема настройки#

Формат ключей OAuth2/OIDC-клиентов#

Типовые операции администратора#

Изменение redirect URI клиента#

Изменение client secret#

Изменение набора scopes и claims для клиента#

Изменение маппинга атрибутов профиля UIDM на claims#

Справочник путей к конфигурационным файлам#

Справочник параметров#

Параметры OAuth2/OIDC-клиента#

Тип клиента#

Форматы client secret#

Grant types#

Redirect URI#

Agent origins#

OIDC-параметры#

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

Проверка получения токена системным клиентом#

Проверка OIDC discovery#

Приложение A. Генерация хэша client secret#

Argon2#

bcrypt#

PBKDF2#

Особенности Платформы Astra Cloud#

Настроенные клиенты проекта#

Проектный маппинг claims#

Проектные OIDC-настройки#