Настройка и применение механизмов авторизации для OpenID Connect-приложений через механизм claims based authorization

Общие сведения

В статье описываются механизмы авторизации для OpenID Connect-приложений через claims based authorization. Это вид авторизации, при котором права пользователя или приложения на выполнение действия определяются через "claims" (утверждения), присвоенные этому пользователю или приложению. В случае OpenID Connect, это могут быть стандартные или пользовательские "claims", которые передаются клиенту в ID токене или доступны через UserInfo Endpoint.

Для приложения, подключенного по OpenID Connect, с целью 2FA/MFA/SSO могут использоваться следующие факторы аутентификации: 

• Мобильное приложение Avanpost Authenticator (push + TOTP);
• SMS;
• TOTP;
• E-mail;
• Мессенджер Telegram;
• Электронная подпись;
• FIDO WebAuthn/U2F;
• Доменная Kerberos-аутентификация;
• ЕСИА (Единая система идентификации и аутентификации) в режиме Federation;
• OpenID Connect-провайдер в режиме Federation;
• SAML-провайдер в режиме Federation.

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

Система поддерживает функциональность SSO (Signle Sign-On), обеспечиваемую протоколом OpenID Connect: если пользователь прошёл аутентификацию в веб-приложение в соответствии с настроенным сценарием, то система не будет запрашивать повторного подтверждения аутентификации при аутентификации в другое веб-приложение. Также обеспечивается реализация функциональности SLO (Single Logout)/Backchannel Logout в рамках протокола OpenID Connect.

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

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

При описании claim используется стандарт JWT. JSON Web Token (JWT) — это компактный формат представления claim, предназначенный для работы через Web, например, по протоколу HTTP. Утверждения (claims) описываются URI, т.е., символьной строкой, позволяющей идентифицировать какой-либо ресурс: документ, изображение, файл, службу, ящик электронной почты. Система по умолчанию поддерживает следующие claims из таблицы ниже.

Чтобы добавить свои утверждения, необходимо зайти в административный интерфейс, выбрать приложение OpenId, для которого необходимо добавить утверждение, и внести их на вкладке Scopes (Рисунок). Имя при этом может быть произвольным, но рекомендуется придерживаться стандарта JWT и не допускать дублирования стандартных имен утверждений.

Для проверки работы утверждений после их добавления можно воспользоваться любым сервисом проверки JWT, например, jwt.io.

2FA/MFA и SSO/SLO для веб-приложений

Avanpost FAM может быть использован для реализации SSO/SLO/2FA/MFA-сценариев для веб-приложений при их подключении по OpenID Connect.

Интеграция веб-приложений с Avanpost FAM выполняется посредством стандартных механизмов OpenID Connect. 

Для подключения веб-приложений рекомендуется использование Authorization Code Flow with PKCE.

2FA/MFA и SSO/SLO для десктопных приложений

Avanpost FAM может быть использован для реализации SSO/SLO/2FA/MFA-сценариев для десктопных приложений при их подключении по OpenID Connect. Для унаследованных десктопных приложений без возможности реализации OAuth/OpenID Connect и других IdP-механизмов следует рассмотреть механизм Enterprise SSO. 

Ниже описаны возможные варианты реализации интеграции десктопного приложения с системой Avanpost FAM.

Выбор сценария аутентификации (OAuth 2.0 Flow)

Для Native-приложений допустимо использование следующих сценариев (OAuth 2.0 Flow):

• Authorization Code Flow;
• Authorization Code Flow with PKCE.

Authorization Code Flow следует использовать при наличии у целевого приложения backend на сервере закрытого канала связи до token_endpoint Системы.

Authorization Code Flow with PKCE следует использовать при отсутствии у целевого приложения backend закрытого канала связи до token_endpoint Системы.

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

1. Приложение формирует запрос к authorization_endpoint в соответствии с выбранной схемой (Authorization Code Flow либо Authorization Code Flow with PKCE) и открывает сформированный запрос в WebView внутри приложения.
2. Система в ответ на этот запрос отображает веб-интерфейс аутентификации. Пользователь выполняет аутентификацию в Системе, используя веб-интерфейс Системы.
3. После прохождения аутентификации Система выполняет перенаправление пользователя на адрес, содержащий заполненный HTTP Query String параметр code. Приложение считывает значение параметра code.
4. Приложение формирует запрос, используя полученный code, к token_endpoint Системы и получает в ответ набор токенов (Access Token, ID Token, Refresh Token). Пользователь аутентифицирован.

Приложение А. Endpoint'ы OpenID Connect

Доступные в Avanpost FAM в OpenID Connect Identity Provider методы:

Приложение Б. Структура OpenID Connect-токенов

Токены, используемые приложениями в рамках взаимодействий по OAuth и OpenID Connect, имеют различное предназначение и обладают некоторыми особенностями. Сравнение используемых токенов в Avanpost FAM приведено в таблице: