Identity Cloud : 5.3.1. Управление OpenID Connect-приложениями

[ Добавление OIDC-приложения ] [ Шаг 1. Основные настройки ] [ Шаг 2. Настройки интеграции ] [ Настройка OIDC-приложения ] [ Вкладка "Настройки" ] [ Вкладка "OpenID Connect" ] [ Раздел "Scopes" ] [ Раздел "Обязательные утверждения (Claims)" ] [ Раздел "Модель авторизации" ] [ Раздел "Сертификаты" ] [ Раздел "Доверенные серверы" ] [ Приложение А. Бесшовная идентификация в OIDC-приложении ] [ Приложение Б. Перечень ключей для вычисления значений claim'а с типом «Вычисляемое значение» ]

Avanpost Identity Cloud реализует возможность управления OIDC-приложениями, предоставляя для приложений и систем набор HTTP(S)-методов в соответствии с протоколами OAuth 2.0 и OpenID Connect.

В Identity Cloud стандарт OpenID Concnet используется для подключения внешних веб-приложений, мобильных сервисов и API, которые поддерживают данный протокол. Avanpost Identity Cloud выступает в роли доверенного провайдера идентификации (Identity Provider, IdP), выпуская для клиентских приложений ID-токены, токены доступа (Access Token) и токены обновления (Refresh Token). Администратор может гибко управлять областями доступа (scopes) и утверждениями (claims), включая возможность вычисления значений через скрипты, а также настраивать сроки жизни токенов, стратегии обновления, механизмы завершения сессии и т. п. в соответствии с данной инструкцией. Avanpost Identity Cloud поддерживает все основные типы авторизации и обеспечивает прозрачный единый вход (SSO) с многофакторной аутентификацией (MFA) для корпоративных приложений.

Предположим, что корпоративный портал на базе GitLab интегрируется с Avanpost Identity Cloud по протоколу OIDC. Администратор регистрирует приложение в административной консоли, настраивая параметры в соответствии с текущей инструкцией. После настройки пользователь, обращаясь к GitLab, перенаправляется на страницу аутентификации Avanpost Identity Cloud, где проходит проверку факторов в соответствии с предварительно настроенным сценарием. По завершении аутентификации Avanpost Identity Cloud выдаёт GitLab ID-токен и Access Token, содержащие необходимые атрибуты (например, логин, email, группы пользователя). Таким образом, после первичной аутентификации все последующие переходы в рамках той же сессии происходят без повторного ввода учетных данных.

Добавление OIDC-приложения

Первичная настройка OpenID Connect-приложения осуществляется при добавлении нового приложения. Для этого требуется нажать кнопку "Добавить приложение" в режиме "Приложения" и выполнить настройку в открывшемся интерфейсе. Процесс настройки содержит в себе два шага:

Основные настройки.
Настройки интеграции.

Шаг 1. Основные настройки

На данном шаге продукт предлагает задать значения следующих параметров.

Название параметра	Описание параметра
Наименование	Название приложения
Тип	Типы механизма интеграции приложения: `OAuth/OpenID Connect;` `SAML;` `RADIUS;` `Reverse Proxy;` `Enterprise SSO;` `Windows Logon;` `Linux Logon;` `LDAP Proxy;` `Exchange ActiveSync`. Для настройки OIDC-приложения выбрать опцию "`OAuth/OpenID Connect`"
Процесс аутентификации	Выбрать из выпадающего списка один из настроенных процессов аутентификации
Показывать приложение пользователям	Чекбокс "Показывать приложение пользователям": при установленном флажке приложение будет показываться пользователям в личном кабинете вне зависимости от наличия у них доступа к приложению; при выключенном флажке приложение не будет показываться пользователям, не имеющим доступа к приложению.
Сделать активным	Чекбокс "Сделать приложение активным": при установленном флажке приложение включается сразу после создания; при выключенном флажке приложение выключено после создания: для включения потребуется нажать "Включить приложение" (выпадающий список "Еще" в профиле приложения).

Для перехода к следующему шагу требуется нажать "Вперед" после установки параметров. Для отказа от создания приложения следует нажать "Отмена".

Шаг 2. Настройки интеграции

На данном шаге продукт предлагает ввести следующие параметры.

Название параметра	Описание параметра
Публичное приложение	Чекбокс "Публичное приложение": при активном флажке запрещается программная передача учетных данных (логина и пароля) напрямую от клиента к серверу для входа; при выключенном флажке в качестве идентификатора приложения передается только Client ID.
Секрет клиента (Client Secret)	Произвольный секрет, который будет использоваться для подключения к приложению.
URI перенаправления (Redirect URIs)	URL-адрес, на который пользователь будет перенаправлен после успешной аутентификации.
Базовый URL (Base URL)	URL-адрес, на который пользователь будет перенаправляться при переходе из личного кабинета.
URL выхода (Logout URL)	URL-адрес, на который пользователь будет перенаправлен после выхода из приложения.
Показывать форму подтверждения перехода	Переключатель "Показывать форму подтверждения перехода": при включенном переключателе пользователю после завершения сессии выводится форма подтверждения перехода перед перенаправлением на настроенный URL-адрес; при выключенном переключателе форма подтверждения перехода не выводится.

Для завершения создания приложения требуется нажать "Создать" после установки параметров, для отказа от создания приложения - "Отменить", для возврата к предыдущему шагу - "Назад".

Некоторые внешние приложения автоматически создают пользователей на после первой аутентификации посредством Avanpost FAM. Данное поведение зависит непосредственно от клиентских приложений и на стороне Avanpost FAM не настраивается.

Настройка OIDC-приложения

Настройка созданного OIDC-приложения доступна в его профиле. В профиле осуществляется управление параметрами, общими для всех приложений (функционал профиля приложения описан в разделе Управление приложениями). Также в профиле осуществляется управление специфическими параметрами OIDC-приложений во вкладках "Настройки" и "OpenID Connect".

Вкладка "Настройки"

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

Настройки интеграции OpenID;
Настройки интеграции OpenID Secret;
Настройки безопасности;
Настройки регистрации.
Шифровать утверждения (Claims), передаваемые приложению;
Unified SSO.

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

Вкладка "Настройки" позволяет просматривать и управлять следующими настраиваемыми атрибутами.

Название параметра	Описание параметра
Настройки интеграции OpenID
Client ID	Уникальный идентификатор приложения (не доступен для изменения)
Публичный	Чекбокс "Публичный": при активном флажке запрещается программная передача учетных данных (логина и пароля) напрямую от клиента к серверу для входа; при выключенном флажке в качестве идентификатора приложения передается только Client ID.
ID synonym	Синоним идентификатора приложения.
Base URL приложения	URL-адрес, на который пользователь будет перенаправлен при переходе из личного кабинета.
URI перенаправления (Redirect URIs)	URL-адрес, на который пользователь будет перенаправлен после успешной аутентификации. Допускается указать несколько URL-адресов через пробел. Текстовое поле доступно для настройки, если выключен чекбокс "Отображать экран успешного входа".
Отображать экран успешного входа	Чекбокс "Отображать экран успешного входа": при включенном флаге пользователю отображается стандартный экран успешного входа без перенаправления на другой адрес (использование Redirect URIs недоступно); при выключенном флаге пользователь после успешного входа перенаправляется на адрес, указанный Redirect URIs.
URI для серверного выхода (Backchannel Logout URI)	URL-адрес, на который отправляется запрос для централизованного завершения сессии. Используется для реализации выхода пользователя без перенаправления в браузере (серверный выход). Позволяет провайдеру идентификации (IdP) уведомить клиентское приложение о том, что пользователь вышел из системы, чтобы приложение завершило сессию.
Проксировать серверный выход через сервис	Чекбокс "Проксировать серверный выход через сервис": при включенном флажке механизм Logout проксируется через FAM SelfService (для случаев, когда отсутствует сетевое подключение между FAM Server и интегрируемым OIDC-приложением); при выключенном флажке механизм Logout работает только при наличии сетевого подключения между FAM Server и интегрируемым OIDC-приложением.
URL перенаправления после выхода	URL-адрес (Post logout redirect URIs), на который пользователь будет перенаправлен после централизованного завершения сессии.
Форма подтверждения перехода	Переключатель "Форма подтверждения перехода": при включенном переключателе пользователю после завершения сессии выводится форма подтверждения перехода перед перенаправлением на настроенный URL-адрес; при выключенном переключателе форма подтверждения перехода не выводится.
Audience	Параметр JWT, указывающий, для какого ресурса или сервиса предназначен токен. Avanpost FAM проверяет, что значение в токене совпадает с ожидаемым зачением `Audience`, чтобы исключить использование токена в другом сервисе. Обычно используется `Client ID` или URL ресурса, для которого выпускается токен. Обязательно заполнять, если для параметра Client assertion type выбрано значение `client_secret_jwt` или `private_key_jwt.` Для значения `client_secret_basic` заполнение обычно не требуется.
Тип Audience	Тип параметра Audience выбирается в выпадающем списке из следующих вариантов: `Строка` - Одно значение: при использовании токена JWT для одного ресурса (одного приложения или API); `Массив` - Несколько значений: если планируется использовать JWT для нескольких ресурсов (например, микросервисы внутри одной системы).
Client assertion type	Метод аутентификации клиента, с помощью которого клиент подтверждает свою подлинность при обмене кодов на токены: `client_secret_basic` - Клиенты, получившие значение `client_secret` от Сервера авторизации, проходят аутентификацию на Сервере авторизации, используя базовую схему HTTP-аутентификации (HTTP Basic Authentication): `client_secret` передается в заголовке HTTP-запроса (рекомендуется использовать для приложений с защищенным backend, где `client_secret` можно хранить безопасно); `client_secret_jwt` - Клиенты, получившие значение `client_secret` от Сервера авторизации, создают токен JWT и подписывают его своим `client_secret`, используя алгоритм HMAC SHA, а затем направляют подписанный JWT в FAM для прохождения аутентификации (более безопасный способ в сравнении с HTTP Basic Authentication); `private_key_jwt` - клиент формирует и подписывает JWT своей асимметричной парой ключей (private/public). Рекомендуется использовать для повышения безопасности в случаях, когда нельзя хранить общий секрет (например, в распределенных приложениях).
Алгоритм подписи секрета	Выбор алгоритма подписи секрета из вариантов (параметр появляется, если параметр `Client assertion type` настроен как `client_secret_jwt` или `private_key_jwt`): HS256 — алгоритм HMAC с использованием хеш-функции SHA-256; HS384 — алгоритм HMAC с использованием хеш-функции SHA-384; HS512 — алгоритм HMAC с использованием хеш-функции SHA-512.
URI для JWK Set клиента (Client Assertion JWKs URI)	Адрес, предоставленный доверенной стороной, с которого возвращается JSON Web Key при валидации JSON Web Token (появляется, если параметр Client assertion type настроен как `private_key_jwt`).
Разрешённые способы авторизации (Allowed grant types)	Разрешенные приложению Grant Types, т.е. методы, с помощью которых приложение получает Access token и с помощью которых приложению предоставляется ограниченный доступ к данным Avanpost FAM. Допускается указать несколько вариантов. Доступны следующие Grant Types: `Authorization code` - Access token получается после предоставления клиентом кода авторизации. После перенаправления пользователя к клиенту через Redirect URIs приложение получит код авторизации из URL-адреса и использует его, чтобы запросить Access token. `Implicit` - Упрощенный вариант для приложений, где Access token предоставляется немедленно без дополнительного шага обмена кода авторизации на Access token. `Hybrid` - Комбинированный метод на базе Authorization code grant type и Implicit grant type. ID token передается через канал браузера и содержит подписанный ответ протокола и сигнатуры для других артефактов, например, кода авторизации. `Refresh token` - Когда истекает срок действия старого Access token, новый Access token предоставляется после предъявления клиентом Refresh token. `Password` - Получение Access token посредством предоставления учетных данных пользователя, включая пароль. `Client credentials` - Используется клиентом для получения Access token вне контекста пользователя. Обычно используется для обеспечения доступа клиентов для доступа к собственным ресурсам о себе. Token Exchange – Выполняется обмен существующего токена на новый токен с другими параметрами (например, измененными scopes или временем жизни). Сервер авторизации валидирует входной токен, проверяет права запрашивающей стороны и генерирует новый, строго целевой токен доступа.
Время жизни Access токена (в секундах)	Время действия маркера доступа (Access token).
Тип Access токена	Тип Access token. Допускается выбрать из выпадающего списка: `Случайное значение` – токен представляет собой opaque-строку (произвольный идентификатор), не содержащую данных внутри себя (в данном случае информация о пользователе и его правах хранится в FAM и выдается по специальному запросу к Introspection Endpoint. Использование данного значения более безопасно, т.к. клиентскому приложению передается минимальное количество данных, но требует обращения приложения к FAM Server для получения данных токена. Рекомендуется использовать, если клиентское приложение и Avanpost FAM находятся в одной инфраструктуре, и приложение может делать introspection-запросы (запросы о текущем состоянии и содержимом Access token). `JSON Web Token` – токен содержит внутри claims с данными о пользователе и его правах доступа, подписан сервером. Использование данного значения требует корректной валидации подписи, но более удобно для клиентских приложений, которым требуется читать claims без дополнительных запросов. Рекомендуется использовать для внешних или распределенных внешних приложений, которым требуется обладать полной информацией токена доступа, не выполняя дополнительные запросы.
Время жизни ID токена (в секундах)	Время действия ID token в секундах.
Время жизни Refresh токена (в секундах)	Время действия Refresh token в секундах.
Время жизни Access токена (в секундах)	Время действия Access token в секундах.
Алгоритм подписи JWT	Алгоритм подписи JSON Web Token. Допускается выбрать из выпадающего списка: `RS256 (RSA Signatiure with SHA-256);` `GOST3410_2012_256 (ГОСТ Р 34.10-2012 256).`
Переиспользовать refresh токен	Стратегия использования Refresh token. Чекбокс "Переиспользовать refresh token": при установленном флажке пользователь может повторно использовать refresh token для обновления токена; при выключенном флажке при повторном использовании refresh token отзываются все токены, выданные пользователю ранее.
Стратегия завершения сессии	Политика в отношении токена при завершении сессии: `Clear` `(Очистить)` – Токен очищается от всех привязанных к нему сессий; `None` `(Нет)` – Токен может использоваться после завершения сессии.
Scope (по умолчанию)	Области действия (scope) приложения по умолчанию. Данные scopes действуют вне зависимости от scopes, настраивающихся в соответствующем разделе. Допускается указать несколько scopes, разделив их пробелом.
Обрабатывать как ошибки протокола	Чекбокс "Обрабатывать как ошибки протокола": при установленном флажке OAuth-сервер передает данные об ошибке приложению, т. е. через параметры запроса по `redirect_uri;` при выключенному флажке данные об ошибке не передаются приложению.
Разрешенные источники (Allowed origins)	Список доменов, которым разрешено выполнять CORS-запросы к Avanpost FAM (обычно используется для фронтенд-приложений в браузере). На данные домены не будет действовать правило ограничения домена (Same Origin Policy) на запрашиваемые страницы. Адреса доменов вводятся в текстовое поле и разделяются пробелом. Необходимо заполнять при использовании SPA (Single Page Application) или веб-клиентов, которые обращаются к Avanpost FAM напрямую из браузера. Если приложение работает как backend-сервис и не выполняет прямых CORS-запросов, заполнять поле не требуется.
Настройки интеграции OpenID Secret
Новый секрет	Для смены секрета следует нажать . Новый секрет необходимо ввести в текстовое поле и сохранить. Если секрет не соответствует требованиям безопасности, сохранение нового секрета будет недоступно и появится предупреждение с причиной несоответствия.
Настройки безопасности
Настройка сессии	Чекбокс "Ограничивать количество активных сессий": при выключенном флажке количество сессий не ограничивается; при включенном флажке открываются дополнительные настройки: Максимальное количество сессий для пользователя - Строка ввода максимального количества сессий, доступных одному пользователю. Чекбокс "Разрешить пользователю закрывать активные сессии": при включенном флажке пользователь может самостоятельно завершать активные сессии (при превышении максимального числа сессий у пользователя автоматически возникает окно с возможностью завершения активных сессий); при выключенном флажке пользователю запрещено самостоятельно завершать активные сессии.
Повысить уровень безопасности и отключить SSO для приложения	Чекбокс "Отключить": при выключенном флажке технология единого входа SSO используется для данного приложения; при включенном флажке SSO недоступно для данного приложения.
Настройки регистрации
Статус	Управление функцией самостоятельной регистрации пользователя применительно к приложению. Информация о всех возможностях управления саморегистрацией доступна в разделе Самостоятельная регистрация пользователей. Выбрать из выпадающего списка: `По умолчанию` - К пользователю применяется общая политика регистрации, настроенная для Avanpost FAM; `Включена` - Пользователю доступна самостоятельная регистрация при входе в приложение; `Выключена` - Пользователю недоступна самостоятельная регистрация при попытке входа в приложение, добавление пользователей осуществляется иными способами.
URL перенаправления после регистрации	URL-адрес, на который пользователь будет перенаправлен после регистрации. Текстовое поле доступно для заполнения при статусе "Включена".
Шифровать утверждения (Claims), передаваемые приложению
Активировать	Чекбокс активации механизма шифрования Claims на уровне спецификации JWE (JSON Web Encryption).
Выберите файл ключа шифрования	Нажать, чтобы загрузить ключ для шифрования передаваемых Claims.
Наименования утверждений	Строка ввода утверждений (claims), которые FAM будет передавать внутрь токена.
Unified SSO
Включить	Чекбокс "Включить USSO": при включении чекбокса для OIDC-приложения доступно использования специализированного механизма Unified SSO, предназначенного для выполнения кросспротокольной аутентификации при помощи компонента FAM Агент; при выключенном чекбоксе механизм USSO не используется.
Режим для устаревших браузеров	Переключатель "Режим для устаревших браузеров": при включении переключателя поддерживается аутентификация в приложениях с WebView, не поддерживающими кастомные URL-схемы (например, тонкий клиент 1С); при выключенном переключателе работа с устаревшими браузерами не поддерживается.

Вкладка "OpenID Connect"

Во вкладке "OpenID Connect" имеются следующие разделы для тонкой настройки OIDC-приложения:

Scopes;
Обязательные утверждения (Claims);
Модель авторизации;
Сертификаты;
Доверенные серверы.

Раздел "Scopes"

Области доступа (scopes) предоставляют приложению набор пользовательских атрибутов, называемых утверждениями (claims). Настройка scopes, запрашиваемых приложением при аутентификации, зависит от того, с какими пользовательскими атрибутами приложение оперирует.

Вкладка предоставляет расширенные возможности для настройки областей доступа (scopes) приложения и утверждений (claims), которые будут запрошены при аутентификации в OIDC-приложении. Из дополнительных scopes, настроенных в данной вкладке и запрошенных приложением, будут переданы claims в состав JWT-токена.

Список scopes отображается в общем реестре, содержащем:

Название - Наименование scope;
Кнопка - Нажать, чтобы изменить параметры выбранной scope;
Кнопка - Нажать, чтобы Удалить выбранную scope.

Для добавления scopes требуется нажать кнопку "Добавить новый scope", ввести наименование создаваемой области доступа и нажать .

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

Название параметра

Описание параметра

Утверждения (Claims)

Список утверждений для данного scope.

Добавление нового утверждения

Поле содержит реестр с утверждениями (claims). Для одной области действия (scope) может быть настроено несколько утверждений (claims). Для добавления нового утверждения следует задать его параметры и нажать (для отмены ввода нажать ).

При настройкеутверждений (claims) используются следующие параметры и элементы интерфейса:

Наименование - Название данного утверждения;
Тип - Выбор типа атрибута из выпадающего списка:
- Значение из атрибута пользователя;
- Постоянное значение;
- Вычисляемое значение;
Значение, присваиваемое атрибуту для передачи в целевое приложение:
- Для типа утверждения "Значение из атрибута" выбрать атрибут пользователя, из которого присваивается значение для данного утверждения;
- Для типа утверждения "Постоянное значение" ввести значение в текстовое поле;
- Для типа утверждения "Вычисляемое значение" путем нажатия на поле текстовое поле значения перейти в редактор и ввести алгоритм расчета вычисляемого значения (подробнее о вычисления значений claims указано в приложении Б).
Кнопка – Нажать для добавления утверждения (claim) с заданными параметрами;
Кнопка – Нажать для отмены изменений;
Кнопка – Нажать для удаления существующего утверждения (claim) требуется нажать.

Раздел "Обязательные утверждения (Claims)"

Поле "Список утверждений (Claims), обязательных для аутентификации в приложении" содержит список утверждений (claims), которым обязательно должно быть присвоено значение для успешной аутентификации пользователя в приложении. Раздел содержит реестр таких утверждений со следующими параметрами и элементами интерфейса:

Scope – Наименование области действия, к которой принадлежит утверждение, обязательное для аутентификации в приложении;
Утверждение (Claim) – Наименование утверждения (claim). обязательного для аутентификации в приложении;
Кнопка "Добавить" – Следует нажать для добавления утверждения в данный список;
Кнопка – Следует нажать удаления выбранного утверждения (claim) из списка.

При нажатии кнопки "Добавить" откроется форма для добавления утверждения со следующими параметрами и возможностями:

Scope – Выбрать из выпадающего списка доступных областей действия (Scopes);
Утверждение (Claim) – Выбрать из выпадающего списка утверждений, доступных для данной Scope;
Кнопка – Нажать для добавления настроенного утверждения в "Список утверждений (Claims), обязательных для аутентификации в приложении";
Кнопка – Нажать для отмены изменений.

Раздел "Модель авторизации"

Вкладка позволяет настраивать модель доступа, используемую при настройке полномочий роли в отношении целевого приложения. Механизм модели доступа реализуется для протокола управления доступом UMA (User-Managed Access) на основе OAuth 2.0.

Модель доступа строится на существовании объектов доступа (Resourse) внутри целевого приложения и прав (Scopes), которые получает пользователь в отношении объектов доступа после аутентификации в Avanpost FAM. После настройки модели доступа для OIDC-приложения администратор может предоставлять те или иные права (scopes) в отношении объектов доступа (Resourse) ролям, настраиваемым в Avanpost FAM во вкладке "Настройки ролей и прав". Роли с назначенными правами присваиваются пользователям.

Avanpost FAM также содержит ряд внутренних объектов доступа (Resourse) и прав (Scopes). Модели доступа в отношении внутренних функциональных элементов Avanpost FAM не редактируются. Администратор назначает права в отношении объектов доступа внутри Avanpost FAM через механизм управления ролями, пользуясь предустановленными моделями доступа.

Механизм использования модели доступа в ролевой модели описан в разделе Настройки ролей и прав.

Вкладка "Модель доступа" содержит список объектов доступа со следующим данными и возможностями:

Объект доступа (Resource) – Название объекта доступа;
Количество прав – Количество прав (scopes), настроенных для объекта доступа;
Кнопка – Нажать для изменения настроек выбранного объекта доступа;
Кнопка – Нажать для удаления объекта доступа (после подтверждения).

Для добавления нового объекта доступа, к которому настраивается доступ, требуется нажать "Добавить новый объект доступа". Значения параметров объектов доступа (Resource) и прав (Scopes) должны соответствовать значениям Resourse и Scopes в целевом приложении. В открывшейся форме нужно ввести следующие параметры:

Название ресурса – Название объекта доступа (отображается в "Объект доступа (Resource)" реестра объектов доступа);
Код ресурса – Код объекта доступа.

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

Параметр

Значение

Права (Scopes)

Список прав (scopes) для данного объекта доступа (Resource).

Добавление нового разрешения

В форме содержатся список разрешений и имеется возможность создания нового утверждения. При настройке разрешения используются следующие параметры и элементы интерфейса:

Код – Код объекта доступа;
Название ресурса – Название объекта доступа (отображается в "Объект доступа (Resource)" реестра объектов доступа)
Кнопка – Нажать для добавления настроенного разрешения;
Кнопка – Нажать для отмены изменений;
Кнопка – Удалить разрешение.

Раздел "Сертификаты"

Раздел позволяет управлять криптографическими ключами JSON Web Key Sets для OIDC-приложения. Для подписи JWT-токенов в OIDC-приложениях используются алгоритмы RS256 и HS256. Алгоритм RS256 генерирует асимметричную подпись, то есть для подписи JWT-токена используется закрытый ключ, а для проверки подписи - открытый ключ. JSON Web Key Set (JWKS) представляет собой набор публичных ключей, используемых для проверки токенов JWT-токенов, выданных сервером авторизации и подписанных с использованием алгоритма RS256 (или GOST3410_2012_256).

Раздел содержит реестр сертификатов, в котором отражаются следующие данные:

Алгоритм - Тип алгоритма для подписи JWT-токена:
- RS256 (RSA Signatiure with SHA-256);
- GOST3410_2012_256 (ГОСТ Р 34.10-2012 256);
Key ID - Идентификатор ключа.

Чтобы добавить новый сертификат, требуется нажать "Настроить" и ввести ключ в редакторе. Чтобы сохранить сертификат, следует нажать "Сохранить". Для отмены изменений следует нажать "Отмена".

Раздел "Доверенные серверы"

Раздел «Доверенные серверы» предназначен для настройки доверительных отношений между Avanpost FAM и внешними OpenID Connect-провайдерами. Данный механизм используется в сценариях федеративной аутентификации (OIDC Federation), кросспротокольного механизма аутентификации и интеграции с внешними Identity Provider.

Раздел содержит реестр доверенных серверов, в котором отражаются следующие данные и элементы интерфейса:

Приложения – Данные клиентских приложений на стороне FAM, с которыми могут взаимодействовать доверенные сервера.
Metadata URL – адрес внешнего OIDC-провайдера, предоставляющей метаданные в формате JSON, куда FAM автоматически загружает конфигурацию провайдера по указанному URL для установления доверительных отношений;
Кнопка – Нажать для изменения настроек выбранного сервера;
Кнопка – Нажать для удаления выбранного сервера.

Для добавления нового доверенного сервера необходимо нажать "Добавить новый доверенный сервер", после чего ввести следующие данные:

Metadata URL – ввести адрес внешнего доверенного сервера: выбрать протокол (HTTP/HTTPS) и указать путь;
Кнопка – Нажать для добавления настроенного сервера;
Кнопка – Нажать для отмены изменений.

Чтобы добавить для созданного доверенного сервера новые OIDC-приложения следует нажать и задать параметры. В открывшемся интерфейсе имеются следующие параметры:

Параметр

Значение

Приложения

Список OIDC-приложений для данного доверенного сервера.

Добавление нового приложения

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

Client ID – Уникальный идентификатор OIDC-приложения;
Client Secret – Cекрет, который используется для подключения к приложению;
Кнопка – Нажать для добавления настроенного приложения;
Кнопка – Нажать для отмены изменений;
Кнопка – Удалить приложение из привязанных к данному доверенному серверу.

Приложение А. Бесшовная идентификация в OIDC-приложении

Для бесшовной идентификации пользователя в OpenID-приложении через IFrame можно использовать HTTP-метод POST вместо стандартного метода GET. Данный позволяет передавать идентификатор (логин) пользователя напрямую в запросе авторизации. Этап идентификации пользователя будет пропущен, так как логин уже передан в HTTP-запросе. В частности, рекомендуется использовать при интеграции с ADFS, когда логин пользователя известен на момент инициализации аутентификации и может быть направлен Identity Cloud для бесшовного продолжения процесса авторизации. Ниже приведен пример создания iframe и скрытой формы с последующим выполнением скрипта для автоматической идентификации пользователя.

Пример запроса

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>

<form id="hiddenForm" type="hidden" target="famFrame" action="[CLOUD_AUTH_PAGE]" method="post">
        <input type="hidden" name="identificator" id="username" value="[CLOUD_USER_LOGIN]" />
</form>

<iframe
        name="famFrame"
        style="width: 430px; height: 680px; left: 50%; top: 50%; margin-left: -215px; margin-top: -340px; position: absolute; border: 0; box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19);">
</iframe>

<script>
        let form = document.getElementById("hiddenForm")
        form.submit()
</script>

Основные параметры, передаваемые в запросе POST, указаны в таблице:

Параметр	Значение
`id`	Идентификатор формы.
`type`	Тип формы.
`target`	Фрейм, в который загружается результат. В данном примере указывается, что результат отправки формы должен быть загружен в фрейм с именем famFrame.
`action`	Ссылка на authorization endpoint. Допускается передать на данную конечную точку значение `login_hint` (параметр для предварительного заполнения формы входа идентификатором пользователя), содержащий идентификатор (логин, номер телефона, Email) пользователя.
`method`	Тип HTTP-метода (POST).
`input type`	Тип формы поля ввода (в данном примере `hidden`, т.е. поле ввода скрыто и не отображается пользователю).
`name`	Имя поля, используемое при отправке данных на сервер (`identificator`).
`id`	Тип передаваемого идентификатора пользователя (в данном примере `username`, т.е. логин)
`value`	Значение передаваемого идентификатора пользователя (логин, номер телефона, Email).

Приложение Б. Перечень ключей для вычисления значений claim'а с типом «Вычисляемое значение»

Настройка произвольных Scopes и Claims для каждого OpenID Connect-приложения выполняется с вычислением значения на основе JavaScript-сценария (ECMAScript-скрипта).

При выборе типа значения для claim «Вычисляемое значение» можно использовать следующий перечень стандартных ключей:

Атрибут	Обращение в коде	Содержащееся значение
`id`	`user.id`	Внутренний UUID-идентификатор пользователя
`userName`	`user.userName`	Логин пользователя
`familyName`	`user.familyName`	Фамилия
`givenName`	`user.givenName`	Имя
`middleName`	`user.middleName`	Отчество
`email`	`user.email`	Адрес E-mail
`emailVerified`	`user.emailVerified`	Признак того, что E-mail подтверждён
`locale`	`user.locale`	Локаль пользователя
`phoneNumber`	`user.phoneNumber`	Номер телефона
`phoneNumberVerified`	`user.phoneNumberVerified`	Признак того, что номер телефона подтверждён
`updatedAt`	`user.updatedAt`	Метка времени (timestamp) последнего обновления записи пользователя
`domain`	`user.domain`	Домен пользователя
`isLocked`	`user.isLocked`	Блокировка пользователя

Для обращения к значению дополнительного атрибута следует использовать обращение через ключ user.extra., добавляя наименование дополнительного атрибута. К примеру, для обращения к значению дополнительного атрибута snils следует использовать ключ user.extra.snils.