Использование инфраструктуры OpenID Connect профиля WebSphere Application Server Liberty

Comments

Часть 1. Поддержка инфраструктуры OIDC профиля Liberty

OIDC 1.0 (OpenID Connect) – это простая инфраструктура идентификации, функционирующая "поверх" инфраструктуры OAuth 2.0. В Интернете протокол OIDC все шире применяется для реализации технологии SSO; он хорошо работает с облачными, мобильными и нативными приложениями. Инфраструктура OIDC позволяет клиентскому приложению (например, облачному или мобильному приложению) представить запрос на идентификацию пользователя в виде идентификационного токена (ID token), причем стандартизированным REST-подобным образом. Кроме того, для получения доступа к REST-подобным сервисам клиентское приложение может использовать токены доступа (access token).

OIDC-поставщик профиля Liberty реализован как расширение инфраструктуры OAuth 2.0; его можно использовать в качестве обычного поставщика авторизационных сервисов OAuth 2.0, который выпускает токены доступа OAuth 2.0 и поддерживает все типы разрешений OAuth 2.0.

Предварительные условия

  • Базовое понимание протоколов OIDC и OAuth 2.0. Такое понимание не является необходимостью при выполнении конфигурационных мероприятий, однако оно требуется для оценки воздействия влияния OIDC на безопасность вашей организации.
  • Базовое понимание профиля Liberty, включая знакомство с такими аспектами, как установка, создание сервера и обновление конфигурации сервера.
  • Профиль Liberty версии V8.5.5.4 или позднее, с опциями OIDC, установленными согласно инструкции. Перейдите в папку <liberty_root>/bin и выполните следующие две команды:
     featureManager install openidConnectServer-1.0 --when-file-exists=ignore featureManager install openidConnectClient-1.0 --when-file-exists=ignore

Архитектура OIDC

В архитектуре OIDC используются следующие ключевые понятия: конечный пользователь (End-User), доверяющая сторона (Relying Party) и поставщик OIDC-сервисов (OIDC Provider) или сокращенно OIDC-поставщик (рис. 1).

Рисунок 1. Ключевые понятия OIDC
Key OIDC terms
Key OIDC terms

В версии Liberty V8.5.5.4 были реализованы два важные конфигурационные опции высокого уровня.

  • Liberty OIDC Provider (OIDC-поставщик профиля Liberty) – Выделенный экземпляр Liberty может быть сконфигурирован как поставщик OIDC-сервисов и SSO-сервер. Любое клиентское приложение может вызвать RESTful-сервис безопасности, предоставляемый поставщиком OIDC-сервисов, чтобы запросить или проверить идентификационные данные конечного пользователя и профили пользователей.
  • Liberty OIDC Relying Party (доверяющая сторона OIDC профиля Liberty) – Экземпляр Liberty может быть сконфигурирован как доверяющая сторона OIDC (OIDC Relying Party), чтобы задействовать возможности SSO и использовать поставщика OIDC-сервисов в качестве поставщика идентификационных данных. В этом случае контейнер безопасности Liberty сможет обратиться к поставщику OIDC-сервисов с целью проверки идентификационных данных конечного пользователя вместо того чтобы самому заниматься проверкой этого пользователя.

В версии WebSphere Application Server Full Profile V8.5.5.3 также добавлена поддержка OIDC Relying Party; эта версия может быть участником среды Web SSO вместе с поставщиком OIDC-сервисов.

Web SSO и дополнительный сценарий распространения идентификационных данных

На рис. 2 ниже показан типичный сценарий Web SSO и распространения идентификационных данных с использованием технологий OIDC, в котором имеется три Liberty-сервера в трех зонах безопасности. Эти серверы могут представлять отдельные подразделения или разные компании. Сервер доверяющей стороны запрашивает идентификационные данные пользователей у SSO-сервера поставщика OIDC-сервисов. Сервер доверяющей стороны использует уже аутентифицированные идентификационные данные для последующего запроса ресурсов у сервера ресурсов, а сервер ресурсов проверяет идентификационные данные вызывающей стороны на сервере поставщика OIDC-сервисов. Затем сервер доверяющей стороны и сервер ресурсов используют идентификационный токен или JSON-объект от поставщика OIDC-сервисов, чтобы создать JAAS-субъект, который представляет пользователя и обеспечивает доступ к ресурсу.

Сервер поставщика OIDC-сервисов является SSO-сервером, поэтому пользователю нужно лишь один раз войти в систему поставщика OIDC-сервисов. После успешной аутентификации с поставщиком OIDC-сервисов пользователь может запросить санкционированный доступ у нескольких выступающих в качестве доверяющей стороны защищенных серверов, которые являются участниками SSO-среды совместно с этим поставщиком OIDC-сервисов.

Рисунок 2. OIDC-потоки в Liberty
OIDC flows in Liberty Profile
OIDC flows in Liberty Profile

Компоненты инфраструктуры OIDC

  • Конечные точки. OIDC-поставщик профиля Liberty реализован как расширение инфраструктуры OAuth 2.0. Помимо всех функций OIDC, поставщик OIDC поддерживает все функции OAuth 2.0. OIDC-поставщик профиля Liberty поддерживает следующие конечные точки.
    • Authorization
    • Token
    • Introspection
    • UserInfo
    • Discovery
    • Coverage map
    • Registration
    Рисунок 3. Конечные точки OIDC 1.0 и OAuth 2.0 в среде Liberty
     OIDC 1.0 and OAuth 2.0 endpoints in Liberty Profile
    OIDC 1.0 and OAuth 2.0 endpoints in Liberty Profile
  • Типы разрешений. OIDC-поставщик профиля Liberty поддерживает все типы разрешений OAuth 2.0, включая следующие.
    • authorization_code
    • implicit
    • refresh_token
    • client_credentials
    • password
    • urn:ietf:params:oauth:grant-type:jwt-bearer
  • Множественная аренда. Liberty-сервер поддерживает несколько экземпляров OIDC-поставщиков; каждый из этих экземпляров имеет свои URL-адреса конечных точек, свою форму подтверждения (consent), свою форму входа в систему и управляет своими клиентами и токенами.
  • Гибкая аутентификация. В дополнение к непосредственной аутентификации с помощью LDAP-реестра пользователей OIDC-поставщик профиля Liberty можно быть сконфигурировать на делегирование аутентификации пользователя – при посредстве специального TAI-компонента – стороннему сервису аутентификации, такому как сайт социальной сети, сервер SPNEGO или поставщик идентификационных данных SAML. При наличии OIDC-поставщика профиля Liberty вы сможете легко интегрировать OIDC-сервисы с существующими на вашем предприятии идентификационными сервисами.
  • Доверие и целостность. OIDC-поставщик профиля Liberty в цифровой форме подписывает идентификационный токен с использованием собственного секретного ключа клиента или секретного ключа поставщика; идентификационный токен всегда сопровождается токеном доступа.
  • Администрируемая и защищаемая динамическая регистрация клиента.
  • Гибко настраиваемый поставщик. OIDC-поставщик профиля Liberty предоставляет настраиваемые формы подтверждений, формы входа в систему, посредничество при использовании токенов и посредничество при авторизации.
  • Идентификационный токен. Идентификационный токен имеет достаточно claim-артефактов для воссоздания JAAS-субъекта и может быть расширен с целью предоставления специальных claim-артефактов. Следующий JSON-код представляет собой типичный идентификационный токен, созданный OIDC-поставщиком профиля Liberty.
    Пример идентификационного токена в профиле Liberty
     { "iss":"https://acme.com/oidc/endpoint/idp", "sub":"marissa", "aud":"voting_application", "iat":1385062578, "exp":1385066178 "at_hash":”6820876yree” , “realmName”: “ldap://acme.com:389”, "uniqueSecurityName": "cn=malissa, o=acme", “groupIds”: [ “cn=board member, o=acme”, “cn=executive member, o=acme” ] , }
  • Репозитарии. Поставщики OIDC-сервисов имеют репозитарии двух типов.
    • localStore -- Зарегистрированные клиенты хранятся локально в файле server.xml внутри элементов хранилища localStore. Идентификационный токен, токены доступа и токен обновления находятся в памяти, а подтверждения пользователей (user consent) кэшируются в HTTP-сессии. В режиме localStore конечная точка регистрации клиента поддерживает только операцию чтения.
    • databaseStore -- Зарегистрированные клиенты, токен доступа, идентификационный токен, токен обновления и подтверждение пользователя хранятся в базе данных. Токены и подтверждения пользователей являются персистентными и автоматически восстанавливаются даже после перезапуска поставщика OIDC-сервисов. Полная функциональность конечной точки регистрации клиента (включая такие операции, как создание, чтение, обновление и удаление) поддерживается только в режиме databaseStore.

В профиле Liberty спецификация OIDC реализована в полном объеме. Для получения дополнительной информации по OIDC посетите веб-сайт OpenID Connect. Для получения дополнительной информации по конфигурированию OIDC в профиле Liberty обратитесь к теме OpenID Connect в справочной системе по продукту WebSphere Application Server.

Часть 2. Пример Web SSO на основе OIDC-средств профиля Liberty

Во второй части этого учебного пособия описывается настройка базового сценария Web SSO на основе OIDC-средств профиля Liberty.

Рисунок 4. Сценарий Web SSO на основе OIDC
OIDC web SSO scenario
OIDC web SSO scenario

Настройка поставщика OIDC-сервисов

Создайте экземпляр Liberty-сервера для поставщика OIDC-сервисов. Перейдите в папку <liberty_root>/bin и выполните команду server create <server_name>. В этом примере используется имя сервера oidcServer. Найдите файл server.xml в следующем месте <liberty_root>/usr/servers/ oidcServer/server.xml, откройте этот файл в редакторе и внесите в него следующие изменения.

  1. В разделе <featureManager> добавьте все опции из следующего списка, которые отсутствуют в вашем определении сервера. В результате этого будут активированы опции, необходимые поставщику OIDC-сервисов.
    Список необходимых опций профиля Liberty
     <featureManager> <feature>openidConnectServer-1.0</feature> <feature>ssl-1.0</feature> <feature>appSecurity-2.0</feature> <feature>servlet-3.0</feature> </featureManager>

    Вы можете добавить строку <feature>ldapRegistry-3.0</feature>, если хотите применить LDAP-реестр пользователей для аутентификации пользователей. LDAP необходимо применять в том случае, если вы хотите воспользоваться конечной точкой OIDC UseriInfo.

  2. Присвойте элементу httpEndpoint имя хоста машины, чтобы обрабатывать запросы на удаленное тестирование и убедиться в том, что https-порт определен.
     <httpEndpoint id="defaultHttpEndpoint" host="op.example.com" httpPort="80" httpsPort="443" />
  3. Добавьте хранилище KeyStore, чтобы активировать технологию SSL:
     <keyStore id="defaultKeyStore" password="keypass" />
  4. Если LDAP-реестр не сконфигурирован, добавьте несколько пробных пользователей для тестирования.
     <basicRegistry id="basic" realm=" OpBasicRealm "> <user name="user1" password="security" /> </basicRegistry>

Определение поставщика OAuth-сервисов

Протокол OIDC функционирует поверх протокола OAuth 2.0; вам необходимо сконфигурировать действительного поставщика OAuth-сервисов, включая соответствующие oauth-роли и элементы oauthProvider.

Создание oauth-роли. Любому авторизованному пользователю, которому разрешено использовать OIDC, должна быть присвоена oauth-роль. Для иллюстрации в этом примере oauth-роль присваивается всем аутентифицированным пользователям.

 <oauth-roles> <authenticated> <special-subject type="ALL_AUTHENTICATED_USERS" /> </authenticated> </oauth-roles>

Создание элемента oauthProvider. Этот элемент определяет настраиваемую страницу входа в систему, настраиваемое подтверждение, различные параметры тайм-аута, хранилища клиентов и так далее. OIDC-поставщик профиля Liberty предоставляет значения по умолчанию для большинства обязательных параметров; необходимо задать лишь один элемент конфигурации – хранилище клиентов. В этом примере используется хранилище localStore.

 <oauthProvider id="Oauth" > <localStore </localStore> </oauthProvider>

Регистрация клиентов. OIDC-поставщик профиля Liberty требует, чтобы все клиенты были зарегистрированы и сохранены в хранилище localStore или databaseStore. Каждый зарегистрированный клиент имеет атрибуты name, secret, displayname, redirect, scope, preAuthorizedScope, а также некоторые другие. Регистрация клиента осуществляется позднее. Ниже показан пример клиента в хранилище localStore.

 <client name="oidcclient" secret="{xor}LDo8LTor" displayname="sample client" redirect="https://client.example.com:443/oauthclient/redirect.jsp" scope="openid profile scope1 email phone address" preAuthorizedScope="openid profile" enabled="true"/>

Определение поставщика OIDC-сервисов

На следующем шаге создается элемент openidConnectProvider, присваивается значение идентификатору (ID) и создается ссылка на ранее созданный элемент oauthProvider.

Значение идентификатора является существенным параметром. Например, если для элемента openidConnectProvider вы присвоили идентификатору значение "OP" с помощью выражения id="OP", то строка "OP" используется в URL-адресах конечной точки OIDC, ваша конечная точка авторизации имеет вид https://<host_name>:<port_number>/oidc/endpoint/OP/authorize, а конечная точка токена имеет вид https://<host_name>:<port_number>/oidc/endpoint/OP/token.

Вы можете изменять значение ID, определяя различные конечные точки OIDC. Ниже показана простая конфигурация OIDC-поставщика, в которой конечная точка авторизации определена следующим образом: https://op.example.com:443/oidc/endpoint/OP/authorize.

 <openidConnectProvider id="OP" oauthProviderRef="Oauth" > </openidConnectProvider>

Пример OIDC-поставщика.

 <openidConnectProvider id="OP" oauthProviderRef="Oauth" > </openidConnectProvider> <oauthProvider id="Oauth" > <localStore> <client name="oidcclient" secret="{xor}LDo8LTor" displayname="client001" redirect="https://client.example.com:443/oauthclient/redirect.jsp" scope="openid profile scope1 email phone address" preAuthorizedScope="openid profile" enabled="true"/> </localStore> </oauthProvider> <oauth-roles> <authenticated> <special-subject type="ALL_AUTHENTICATED_USERS" /> </authenticated> </oauth-roles>

На этом настройка поставщика OIDC-сервисов завершена. Ниже показан пример файла server.xml, предоставляющего OIDC-сервисы.

Конфигурация поставщика OIDC-сервисов с фиктивным клиентом в профиле Liberty
 <server> <featureManager> <feature>openidConnectServer-1.0</feature> <feature>ssl-1.0</feature> <feature>appSecurity-2.0</feature> <feature>servlet-3.0</feature> </featureManager> <basicRegistry id="basic" realm="OpBasicRealm"> <user name="user1" password="security" /> <user name="user2" password="security" /> </basicRegistry> <keyStore id="defaultKeyStore" password="keyspass" /> <httpEndpoint host="op.example.com" httpPort="80" httpsPort="443" id="defaultHttpEndpoint"/> <oauth-roles> <authenticated> <special-subject type="ALL_AUTHENTICATED_USERS" /> </authenticated> </oauth-roles> <openidConnectProvider id="OP" oauthProviderRef="Oauth" > </openidConnectProvider> <oauthProvider id="Oauth" > <localStore> <client name="dummy" secret="{xor}LDo8LTor" displayname="dummy" redirect="https://localhost:8020/oauthclient/redirect.jsp" scope="openid profile scope1 email phone address" preAuthorizedScope="openid" enabled="true"/> </localStore> </oauthProvider> </server>

Настройка доверяющей стороны OIDC

Создайте новый сервер в профиле Liberty. Перейдите в папку <liberty_root>/bin и выполните команду server create <server_name>. В этом примере используется имя сервера oidcRP. Найдите файл server.xml в <liberty_root>/usr/servers/<server_name>/server.xml, откройте его в редакторе и внесите в него следующие изменения.

  1. В разделе <featureManager> добавьте все опции из следующего списка, которые отсутствуют в вашем определении сервера. В результате будут активированы опции, необходимые доверяющей стороне OIDC.
    Список опций доверяющей стороны в профиле Liberty
     <featureManager> <feature>ssl-1.0</feature> <feature>jsp-2.2</feature> <feature>servlet-3.0</feature> <feature>appSecurity-2.0</feature> <feature>openidConnectClient-1.0</feature> </featureManager>

    Строка <feature>ldapRegistry-3.0</feature> не нужна, если доверяющая сторона не собирается убеждаться в том, что имя пользователя в id_token от провайдера OIDC присутствует в реестре доверяющей стороны.

  2. Присвойте элементу httpEndpoint имя хоста машины, чтобы обрабатывать запросы на удаленное тестирование и гарантировать наличие определенного https-порта. Если вы создаете OIDC-поставщика и доверяющую сторону на одном и том же сервере, проследите, чтобы они использовали разные порты httpPort и httpsPort.
     <httpEndpoint id="defaultHttpEndpoint" host="rp.example.com" httpPort="80" httpsPort="443" />
  3. Добавьте хранилище KeyStore, чтобы активировать SSL: <keyStore id="defaultKeyStore" password="keypass" />. Хранилища keystore и truststore по умолчанию расположены в следующем месте: <liberty_root>/usr/servers/<server_name>/resources/ security/key.jks. Обязательно импортируйте сертификат OIDC-поставщика в хранилище truststore, поскольку он требуется принимающей стороне для получения токенов от OIDC-поставщика.
  4. Создайте элемент openidConnectClient, который будет содержать информацию о OIDC-поставщике. Ниже показан пример элемента openidConnectClient.
     <openidConnectClient id="oidcRP" clientId="rp" clientSecret="{xor}LDo8LTor" authorizationEndpointUrl="https://op.example.com:443/oidc/endpoint/OP/authorize" tokenEndpointUrl="https://op.example.com:443/oidc/endpoint/OP/token"> </openidConnectClient>

Внутри элемента openidConnectClient вы должны определить атрибуты "clientId" и "clientSecret" с учетом того, что "client_id" и "client_secret" – это удостоверения (credentials) клиента в поставщике OIDC-сервисов, определенные в метаданных клиента OAuth 2.0. В зависимости от соглашений между доверяющей стороной и поставщиком OIDC-сервисов эти два значения может предоставлять либо доверяющая сторона, либо поставщик OIDC-сервисов. Мы отредактируем их позднее.

Доверяющая сторона профиля Liberty предоставляет значения по умолчанию для своего атрибута redirect_url и для требуемой области действия. По умолчанию поставщик OIDC-сервисов профиля Liberty запрашивает область действия вида opened profile (открытый профиль), а администратор может использовать атрибут scope (область действия) для изменения требуемой области действия. Значение redirect_url вычисляется следующим образом: https://<host name>:<ssl port>/oidcclient/redirect/oidcRP, где фрагмент oidcclient/redirect фиксирован, а другие фрагменты могут быть изменены. Фрагмент /oidcRP должен представлять собой значение идентификатора компонента openidConnectClient; вычисление значений host name (имя хоста) и ssl port (ssl-порт) осуществляется в веб-контейнере.

Регистрация доверяющей стороны в поставщике OIDC-сервисов

Чтобы принять запрос на авторизацию от доверяющей стороны, поставщик OIDC-сервисов должен зарегистрировать доверяющую сторону как OAuth-клиента.

  1. Подготовьте регистрационные данные доверяющей стороны. В качестве клиента доверяющая сторона имеет следующие регистрационные атрибуты: name, secret, displayname, redirect, scope, preAuthorizedScope, а также другие атрибуты. Обычно доверяющая сторона в ходе регистрации предоставляет атрибут redirect поставщику OIDC-сервисов, а поставщик OIDC-сервисов присваивает значения всем остальным атрибутам, однако это является предметом согласования между поставщиком OIDC-сервисов и доверяющей стороной. Предположим, что доверяющая сторона предоставляет только следующий атрибут redirect: https://rp.example.com:443/oidcclient/redirect/oidcRP.
  2. Добавьте доверяющую сторону в хранилище localStore для клиентов поставщика OIDC-сервисов. Предположим, что поставщик OIDC-сервисов присваивает всем атрибутам клиента доверяющей стороны, за исключением атрибута redirect, следующие значения: name="rp_1", displayname = "test RP", Secret = "RP's secret", and scope = "opened profile email address phone". Тогда запись клиента для доверяющей стороны имеет следующий вид.
     <client name="RP_1" secret="RP's secret" displayname="test RP" redirect=" https://rp.example.com:443/oidcclient/redirect/oidcRP " scope="openid profile email phone address" enabled="true"/>
  3. Отредактируйте элемент openidConnectClient в файле server.xml доверяющей стороны, изменив значения clientId и clientSecret. Элемент openidConnectClient в файле server.xml доверяющей стороны определяется следующим образом.
     <openidConnectClient id="oidcRP" clientId="RP_1" clientSecret="RP's secret" authorizationEndpointUrl="https://op.example.com:443/oidc/endpoint/OP/authorize" tokenEndpointUrl="https://op.example.com:443/oidc/endpoint/OP/token"> </openidConnectClient>

Обмен сертификатом

Для того чтобы доверяющая сторона могла запрашивать токены у поставщика OIDC-сервисов, она должна импортировать OIDC-сертификат поставщика OIDC-сервисов в хранилище trust store доверяющей стороны. В этом примере один тот же файл SSL-ключей использует и для поставщика OIDC-сервисов, и для доверяющей стороны.

Развертывание приложений у доверяющей стороны

  1. Загрузите файл testpage.war с примером веб-приложения в конце данного учебного пособия. Установите это приложение, скопировав его в каталог <liberty_root>/usr/servers/<server_name>/apps/. Вы можете использовать любое веб-приложение, для которого определены ограничения безопасности и роли.
  2. Сконфигурируйте веб-приложение для защищенного доступа, как показано ниже.
     <application type="war" id="testpage" name="testpage" location="${server.config.dir}/apps/testpage.war"> <application-bnd> <security-role name="All Role"> <special-subject type="ALL_AUTHENTICATED_USERS" /> </security-role> </application-bnd> </application>

Проверка сценария Web SSO на основе OIDC

  1. Запустите OIDC-поставщика: <liberty_root>/bin/server start oidcOP
  2. Запустите доверяющую сторону OIDC: <liberty_root>/bin/server start oidcRP
  3. Откройте в веб-браузере адрес: https://rp.example.com:443/testpage/
  4. Следуйте инструкциям. В конечном итоге вы должны увидеть следующее окно.
    Рисунок 5
    Figure 5
    Figure 5
Пример файла server.xml принимающей стороны
 <server> <featureManager> <feature>ssl-1.0</feature> <feature>jsp-2.2</feature> <feature>servlet-3.0</feature> <feature>appSecurity-2.0</feature> <feature>openidConnectClient-1.0</feature> </featureManager> <openidConnectClient id="RP" scope="openid profile email photo" clientId="rp" clientSecret="secret" authorizationEndpointUrl="https://op.example.com:443/oidc/endpoint/OP/authorize" tokenEndpointUrl="https://op.example.com:443/oidc/endpoint/OP/token" > </openidConnectClient> <keyStore id="defaultKeyStore" password="keyspass" /> <httpEndpoint host="rp.example.com" httpPort="80" httpsPort="443" id="defaultHttpEndpoint"/> <application type="war" id="testpage" name="testpage" location="${server.config.dir}/apps/testpage.war"> <application-bnd> <security-role name="All Role"> <special-subject type="ALL_AUTHENTICATED_USERS" /> </security-role> </application-bnd> </application> </server>
Пример файла server.xml поставщика OIDC-сервисов
 <server> <featureManager> <feature>openidConnectServer-1.0</feature> <feature>ssl-1.0</feature> <feature>appSecurity-2.0</feature> <feature>servlet-3.0</feature> </featureManager> <basicRegistry id="basic" realm="OpBasicRealm"> <user name="testuser" password="testuserpwd" /> <user name="user1" password="security" /> <user name="user2" password="security" /> </basicRegistry> <keyStore id="defaultKeyStore" password="keyspass" /> <httpEndpoint host="op.example.com" httpPort="80" httpsPort="443" id="defaultHttpEndpoint"/> <oauth-roles> <authenticated> <special-subject type="ALL_AUTHENTICATED_USERS" /> </authenticated> </oauth-roles> <openidConnectProvider id="OP" oauthProviderRef="Oauth" > </openidConnectProvider> <oauthProvider id="Oauth" > <localStore> <client name="rp" secret="{xor}LDo8LTor" displayname="rp" redirect="https://rp.example.com:443/oidcclient/redirect/RP" scope="openid profile scope1 email phone address" enabled="true"/> </localStore> </oauthProvider> </server>

Ресурсы для скачивания


Похожие темы

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=1011177
ArticleTitle=Использование инфраструктуры OpenID Connect профиля WebSphere Application Server Liberty
publish-date=07152015