rh_sso_multi_realm

Обзор Версии Аналитика

Here's the translation of the provided text into Russian:

:scrollbar: :data-uri: :toc2: :linkattrs:

= rh-sso-multi-realm

:numbered:

== Обзор

Эта роль предназначена для развертывания постоянной установки Red Hat Single Sign-On (RH-SSO) на платформе контейнеров OpenShift от Red Hat (OCP).

Она также позволяет управлять (то есть создавать и удалять) настраиваемым количеством реальмов SSO в этой установке RH-SSO.

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

. Обучение с инструктором (ILT), Хакатоны и мастер-классы: + При наличии X количества студентов на ILT, которым требуется RH-SSO, организовать одно центральное многополюсное RH-SSO, где каждому студенту будет назначен свой собственный реальм. + Студенту предоставляются административные учетные данные для его назначенного реальма. + Этот подход может быть более предпочтительным, чем альтернативный вариант, при котором каждый студент настраивает собственное RH-SSO.

. Обучение RH-SSO + Некоторые цели обучения могут быть следующими:

.. Показать развертывание RH-SSO на OCP. + В частности, вариант RH-SSO, который использует OCP для управления ссылками: https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.2/html-single/red_hat_single_sign-on_for_openshift/index#what_is_red_hat_single_sign_on[службу обработки секретов сертификатов x509].

.. Интеграция с внешним SMTP-поставщиком для отправки писем и упрощения процесса саморегистрации пользователей. .. Вызов REST Admin API RH-SSO с использованием токенов доступа и обновления OAuth2.

ПРИМЕЧАНИЕ: Эта роль Ansible пока что не использует link:https://github.com/keycloak/keycloak-operator[Keycloak-operator]. Прежде всего из-за невозможности настроить проверки работоспособности и лимиты в текущей реализации оператора, как описано link:https://keycloak.discourse.group/t/various-issues-with-keycloak-operator/845[здесь]. Список текущих открытых задач, связанных с оператором, можно найти по ссылке link:https://issues.redhat.com/browse/KEYCLOAK-13065?jql=project%20%3D%20KEYCLOAK%20AND%20component%20%3D%20%22Containers%20-%20Operator%22[здесь].

=== Ссылки

. link:https://www.keycloak.org/documentation.html[Последняя документация Keycloak] . link:https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.2/html-single/red_hat_single_sign-on_for_openshift[RH-SSO для OCP] . link:https://docs.openshift.com/container-platform/3.10/dev_guide/secrets.html#service-serving-certificate-secrets[Секреты сертификатов служб OCP]

=== Предположения и требования . Убедитесь, что Ansible установлен на вашем локальном компьютере. + Версия Ansible, на которой была проведена последняя проверка этой роли, составляет: 2.6.5-1 на Fedora 29.

. Эта роль Ansible предполагает наличие удаленного кластера OCP с минимум 6 ГБ ОЗУ и 2 ЦП. + Версия OCP, на которой была проведена последняя проверка этой роли Ansible, составляет: 3.11.43.

. Эта роль Ansible активно использует клиент oc, работающий на вашем локальном компьютере. Убедитесь, что этот клиент oc находится в $PATH вашей локальной среды, и его версия соответствует версии вашего окружения OCP.

. [синий]#Локальный клиент oc должен быть уже аутентифицирован в удаленной среде OCP как пользователь cluster-admin.#

====Wildcard Certificate

Эта роль Ansible предполагает, что ваш уже существующий кластер OCP настроен с сертификатом, подписанным легитимным удостоверяющим центром (например, LetsEncrypt).

ПРИМЕЧАНИЕ: link:https://github.com/redhat-gpe/mw_docs/blob/master/ocp_cluster_workshop.adoc[Мастер-классы по кластерам OCP], которые были получены от Red Hat Partner Demo System (RHPDS) и Red Hat Open Partner Enablement Network (OPEN), уже оборудованы сертификатами LetsEncrypt. Вы можете пропустить этот раздел.

Очень хороший урок по получению сертификата Wildcard LetsEncrypt и его присоединению к вашему кластеру OCP можно найти здесь:

Альтернативой сертификату Wildcard для всего кластера OCP может быть ссылка: https://developers.redhat.com/blog/2019/02/06/using-a-public-certificate-with-red-hat-single-sign-on-keycloak/[защита маршрута RH-SSO с помощью сертификата LetsEncrypt].

== Развертывание RH-SSO

=== Переменные окружения

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

Обновите каждую из следующих переменных и затем выполните:

echo "export OCP_PROJECT_PREFIX=<ваши инициалы>" >> ~/.bashrc # Используется позже в лаборатории при создании проекта OCP echo "export ocp_sso_admin_id=sso0" >> ~/.bashrc

Выполните следующее:

echo "export SSO_SITE_ADMIN_USERNAME=master" >> ~/.bashrc echo "export SSO_SITE_ADMIN_PASSWORD=master" >> ~/.bashrc echo "export rhsso_project=rhsso-$ocp_sso_admin_id" >> ~/.bashrc source ~/.bashrc

OCP wildcard DNS после "apps"; т.е.; 2345.openshift.opentlc.com

примеры:

Code Ready Containers: SUBDOMAIN_BASE=crc.testing

ravello vm : SUBDOMAIN_BASE=oc whoami --show-server | cut -d'-' -f 2 | cut -d':' -f 1

ocp workshop : SUBDOMAIN_BASE=oc whoami --show-server | cut -d'.' -f 2,3,4,5 | cut -d':' -f 1

echo "export SUBDOMAIN_BASE=oc whoami --show-server | cut -d'.' -f 2,3,4,5 | cut -d':' -f 1" >> ~/.bashrc source ~/.bashrc

=== Настройка Ansible

. Установите эту роль: +

$ ansible-galaxy install gpe_mw_ansible.rh_sso_multi_realm --force -p /etc/ansible/roles

  • В качестве альтернативы, вы также можете установить роль локально аналогичным образом:

$ ansible-galaxy install gpe_mw_ansible.rh_sso_multi_realm --force -p $HOME/.ansible/roles

. Создайте плейбук: +

$ echo "

  • hosts: all become: false gather_facts: False vars_files: roles:
    • gpe_mw_ansible.rh_sso_multi_realm " > /tmp/rh_sso_multi_realm.yml

=== Обеспечение RH-SSO

Пространство имен OCP для приложения RH-SSO многополюсного будет принадлежать следующему пользователю: {{ocp_sso_admin_id}}. Пользователю с именем {{ocp_sso_admin_id}} будет назначен кластерный квота для управления пределами и запросами, назначенными для 3scale.

. Убедитесь, что ImageStream находится в пространстве имен openshift: .. redhat-sso73-openshift поток изображений. + Выполните следующее, если этот поток изображений не существует в пространстве имен openshift: +

$ oc create -f https://raw.githubusercontent.com/jboss-container-images/redhat-sso-7-openshift-image/v7.4.0.GA/templates/sso74-image-stream.json -n openshift

. Выполните: +

$ ansible-playbook -i localhost, -c local /tmp/rh_sso_multi_realm.yml
-e"ocp_user_needs_quota=true"
-e"ACTION=create"
-e"SSO_SITE_ADMIN_USERNAME=$SSO_SITE_ADMIN_USERNAME"
-e"SSO_SITE_ADMIN_PASSWORD=$SSO_SITE_ADMIN_PASSWORD"
-e"admin_username=$ocp_sso_admin_id"
-e"subdomain_base=$SUBDOMAIN_BASE"

. Установите переменную окружения, которая ссылается на URL нового развернутого RH-SSO: +

echo "export rhsso_hostname=$(oc get route sso -n rhsso-$ocp_sso_admin_id --template "{{.spec.host}}" -n rhsso-$ocp_sso_admin_id)" >> ~/.bashrc

source ~/.bashrc

. После завершения развертывания просмотрите сертификат, связанный с новым сервером RH-SSO: +

$ echo '' | openssl s_client -connect oc get route sso -n $rhsso_project --template "{{.spec.host}}":443 | more

  • Предполагая, что ваш кластер OCP был развернут с использованием сертификата Wildcard, подписанного удостоверяющим центром LetsEncrypt, ответ должен включать следующее:

... subject=CN = master.3295.openshift.opentlc.com

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 ...

. Если кластер OCP был развернут с использованием LetsEncrypt (или другого легитимного) удостоверяющего центра и получил сертификат Wildcard, вы можете просмотреть детали следующим образом: +

$ curl -v -X GET "https://$rhsso_hostname/auth/realms/master/.well-known/openid-configuration" | python -m json.tool

...

  • subjectAltName: host "sso-rhsso-sso0.apps.3295.openshift.opentlc.com" matched cert's "*.apps.3295.openshift.opentlc.com"

=== Консоль администратора RH-SSO . Откройте веб-браузер и перейдите в консоль master реальма : +

$ echo -en "\nhttps://$rhsso_hostname/auth/admin/master/console\n\n"

. Аутентифицируйтесь, используя значения переменных окружения $SSO_SITE_ADMIN_USERNAME и $SSO_SITE_ADMIN_PASSWORD, используемых при развертывании экземпляра RH-SSO.

. Как администратор сайта RH-SSO, у вас есть полный доступ ко всем ресурсам. + image::images/master_homepage.png[]

=== Удаление RH-SSO

$ ansible-playbook -i localhost, -c local /tmp/rh_sso_multi_realm.yml
-e"ACTION=remove"
-e"subdomain_base=$SUBDOMAIN_BASE"

[[realm_mgmt]] == Создание / Удаление реальмов

RH-SSO позволяет создавать несколько реальмов. Каждый реальм полностью автономен от всех других реальмов.

Этот раздел установки помогает в автоматическом создании реальмов для различных случаев использования.

==== SMTP Поставщики Скорее всего, вы захотите, чтобы реальмы вашего RH-SSO имели возможность отправлять электронные письма. Например, generic realms, настраиваемые в рамках этой роли ansible, конфигурируются для потока регистрации пользователей, который требует от нового пользователя подтвердить регистрацию по ссылке, предоставленной в электронном письме.

В RH-SSO параметры smtp настраиваются в рамках реальма. При развертывании реальмов вы можете указать следующие переменные ansible:

  • smtp_host
  • smtp_userid
  • smtp_passwd

Несколько SMTP-поставщиков с бесплатными планами, с которыми была протестирована эта роль ansible, перечислены ниже:

. SocketLabs: В настоящее время предлагает бесплатный план, позволяющий link:https://www.socketlabs.com/signup/[2000 писем в месяц] . SendGrid: В настоящее время предлагает бесплатный план, позволяющий link:https://sendgrid.com/pricing/[100 писем в день]

=== Общие реальмы

С помощью этого ansible может быть создано настраиваемое количество SSO реальмов на основе значений следующих переменных: first_generic_realm и last_generic_realm.

Если значение last_generic_realm меньше 1, то общие реальмы не будут созданы.

Имя этих общих реальмов может быть настроено, переопределив переменную ansible: realm_base_name.

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

=== KIE Реальм Если при создании реальмов переменная loadKieRealm установлена в true, то будет создан специальный реальм, предназначенный для поддержки сценариев Управления бизнесом и Решений.

. Подробности о выделенном kieRealm следующие:

.. realmId: kieRealm .. URL входа: https://$rhsso_hostname/auth/admin/kieRealm/console .. Идентификатор администратора реальма: ssoRealmAdmin .. Пароль администратора реальма: pam .. Роли, связанные с KIE: ... admin ... kie-server ... kiemgmt ... rest-all

. Подробности о всех пользователях, зарегистрированных в этом реальме, можно узнать следующим образом: +

$ cat templates/kie-realm.json | jq .users

=== CRW Реальм Если при создании реальмов переменная loadCRWRealm установлена в true, то будет создан специальный реальм, предназначенный для поддержки Code Ready Workspaces.

Подробности о выделенном crwRealm

. realmId: crwRealm . URL входа: https://$rhsso_hostname/auth/admin/crwRealm/console . Идентификатор администратора: admin . Пароль администратора: admin

=== OpenShift Реальм

Если при создании реальмов переменная loadOCPRealm установлена в true, то будет создан реальм с названием ocp-realm в вашем RH-SSO. Его цель состоит в том, чтобы служить link:https://access.redhat.com/documentation/en-us/red_hat_jboss_middleware_for_openshift/3/html/red_hat_single_sign-on_for_openshift/tutorials#OSE-SSO-AUTH-TUTE[IdentityProvider для аутентификации в OCP].

Подробности о выделенном ocp-realm следующие:

. realmId: ocp-realm . URL входа: https://$rhsso_hostname/auth/admin/ocp-realm/console . Клиент SSO: ocp-client . Идентификатор администратора: gpte-mgr . Пароль администратора: r3dh4t1! . Пользователи SSO: Настраиваемое число пользователей, связанных с этим реальмом, создаются в соответствии с переменными: start_ocp_user и end_ocp_user + Имя каждого пользователя этого реальма будет начинаться со значения: {{ocp_realm_user_base_name}} (по умолчанию = ocp)

. ОПС-похожие роли: + Нет. Роли должны назначаться администратором кластера.

После развертывания ocp-realm в RH-SSO необходимо выполнить несколько дополнительных шагов на главном узле OCP. Подробности об этих шагах содержатся в: {{new_app_output_dir}}/ocp-realm-suggestion.txt В разделе IdentityProvider файла master-config.xml не забудьте переопределить раздел htpasswd с настройками ocp-client.

=== Создание реальмов

. Установите следующие переменные окружения в вашей оболочке, а затем выполните команду ansible, как указано ниже: +

smtp_host= # Подробности поставщика SMTP позволяют RH-SSO отправлять электронные письма в поддержку функциональности, такой как регистрация пользователей smtp_userid= smtp_passwd=

FIRST_GENERIC_REALM=1 # первый реальм для инициализации будет: realm$FIRST_GENERIC_REALM LAST_GENERIC_REALM=1 # последний реальм для инициализации будет : realm$LAST_GENERIC_REALM ; если значение меньше 1, то общие реальмы не будут созданы realm_base_name=realm # базовое имя ваших общих реальмов. По умолчанию это просто: realm.

loadKieRealm=false # по умолчанию false. Если true, то инициализируется реальм, используемый для поддержки установок Red Hat Process Automation и Decision Manager.

loadCRWRealm=false # по умолчанию false. Если true, то инициализируется реальм для поддержки Red Hat Code Ready Workspaces.

crw_redirect_url="" # Применимо только если loadCRWRealm=true. Установить в URL маршрута CodeReadyWorkspace.

loadOCPRealm=true # по умолчанию false. Если true, то настраивается реальм с именем ocp-realm, который можно использовать для настройки OCP на использование RH-SSO для аутентификации. end_ocp_user=1 # последний пользователь, который будет создан в ocp-realm, будет: user$end_ocp_user

$ ansible-playbook -i localhost, -c local /tmp/rh_sso_multi_realm.yml
-e"ACTION=realm_mgmt"
-e"create_realms=true"
-e"subdomain_base=$SUBDOMAIN_BASE"
-e"smtp_host=$smtp_host"
-e"smtp_passwd=$smtp_passwd"
-e"smtp_userid=$smtp_userid"
-e"SSO_SITE_ADMIN_USERNAME=$SSO_SITE_ADMIN_USERNAME"
-e"SSO_SITE_ADMIN_PASSWORD=$SSO_SITE_ADMIN_PASSWORD"
-e"admin_username=$ocp_sso_admin_id"
-e"first_generic_realm=$FIRST_GENERIC_REALM"
-e"last_generic_realm=$LAST_GENERIC_REALM"
-e"realm_base_name=$realm_base_name"
-e"loadKieRealm=$loadKieRealm"
-e"loadCRWRealm=$loadCRWRealm"
-e"crw_redirect_url=$crw_redirect_url"
-e"loadOCPRealm=$loadOCPRealm"
-e"end_ocp_user=$end_ocp_user"
-e"rhsso_hostname=$rhsso_hostname"

. В завершение выполнения ansible, в консоль должно появиться сообщение, подобное следующему: +

rh-sso-multi-realm : Распределение реальмов завершено]

ok: [localhost] => { "msg": [ "create_realms: true", "new_app_output_dir: /home/jbride/provisioning_output/3295.openshift.opentlc.com", "start and end realms = 1 25" ] }

  • JSON-представление каждого созданного реальма можно найти в каталоге, упомянутом как: new_app_output_dir.

==== Удаление реальмов

$ ansible-playbook -i localhost, -c local /tmp/rh_sso_multi_realm.yml
-e"ACTION=realm_mgmt"
-e"first_generic_realm=$FIRST_GENERIC_REALM"
-e"last_generic_realm=$LAST_GENERIC_REALM"
-e"subdomain_base=$SUBDOMAIN_BASE"
-e"SSO_SITE_ADMIN_USERNAME=$SSO_SITE_ADMIN_USERNAME"
-e"SSO_SITE_ADMIN_PASSWORD=$SSO_SITE_ADMIN_PASSWORD"
-e"admin_username=$ocp_sso_admin_id"
-e"rhsso_hostname=$rhsso_hostname"
-e"create_realms=false"

== Общие реальмы: Регистрация пользователей Этот раздел лаборатории предполагает, что вы уже развернули один или несколько общих SSO реальмов в соответствии с разделом <> этой лаборатории.

Цель этого раздела заключается в том, чтобы предоставить студентам инструкции, которые детализируют, как зарегистрироваться как пользователь ранее развернутого общего SSO реальма. Весь этот раздел можно копировать и вставлять в инструкции лаборатории курса, который использует этот многополярный RH-SSO.

. Установите переменную окружения, которая соответствует конкретному реальму (например, <название реальма> = realm1...realm20), который вы хотите использовать: +

$ echo "export rhsso_realm=<название реальма>" >> ~/.bashrc

$ source ~/.bashrc

. Откройте веб-браузер и перейдите в консоль вашего целевого реальма : +

$ echo -en "\nhttps://$rhsso_hostname/auth/admin/$rhsso_realm/console\n\n"

. Нажмите на ссылку Регистрация: + image::images/register_link.png[]

. Заполните все поля регистрационной формы. Убедитесь, что у вас есть действительный адрес электронной почты. . Нажмите Регистрация. . Ожидайте, что ваш браузер перенаправит вас на страницу, указывающую на необходимость подтвердить вашу электронную почту и учетную запись: + image::images/email_verification.png[] . Проверьте свою электронную почту на предмет запроса подтверждения, аналогичного следующему: + image::images/registration_email.png[]

. В электронном письме нажмите на ссылку для подтверждения адреса электронной почты. . Теперь ваш браузер должен быть перенаправлен на домашнюю страницу вашего целевого SSO реальма + image::images/realm_homepage.png[] + ПРИМЕЧАНИЕ: Этот новый зарегистрированный пользователь реальма имеет административный доступ ко всем настройкам реальма.

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

$ realmUserId=<измените меня> $ realmPasswd=<измените меня>

. В вашем браузере перейдите к разделу Клиенты вашего реальма. + Обратите внимание на наличие 5 встроенных SSO клиентов. Каждый из них настроен для поддержки различных OAuth2 и OIDC протоколов. + image::images/default_sso_clients.png[]

=== Общие реальмы: Исследуйте клиентов

Клиент в контексте терминологии OAuth2 — это приложение, запрашивающее доступ к защищенному ресурсу от имени Владельца ресурса. Владелец ресурса обычно является конечным пользователем (также известным как сущность), а защищенный ресурс может содержать конфиденциальные атрибуты от одного или нескольких идентичностей данного Владельца ресурса/сущности.

RH-SSO позволяет создавать пользовательские клиенты. Для целей этой лаборатории вы будете использовать одного из встроенных клиентов, который идет "из коробки" с вашим реальмом.

==== Просмотр realm-management Это только для носителей клиент, который будет связан с защищенной службой бэкэнда в более позднем разделе этой лаборатории. Клиент только для носителей используется для сервисов бэкэнда, которые не инициируют вход в Red Hat SSO, но требуют действительного токена идентификации. Этот токен идентификации обычно используется службой бэкэнда для определения доступа к ресурсам на основе контроля доступа на основе ролей (RBAC).

==== Просмотр admin-cli

В этой лаборатории вы также определяете второй клиент под названием admin-cli. admin-cli является клиентом OAuth2. Вы используете admin-cli позже в этой лаборатории только для тестирования.

Обратите внимание, что admin-cli активирован для использования потока OAuth2, называемого «Идентификация пароля владельца ресурса».

С помощью этого потока клиент позволяет обменивать учетные данные пользователя ID и пароля -- в этом случае, вашего SSO пользователя -- на токен доступа. Этот токен затем может использоваться для доступа к REST API ваших бизнес-служб.

== Общие реальмы: Конечные точки

=== Обзор

Ваш сервер Red Hat SSO реализует конечную точку, называемую well-known, которая перечисляет другие конечные точки и параметры конфигурации, относящиеся к реализации OAuth2/OpenID Connect от Red Hat Single Sign-On.

Цель этого раздела -- ознакомить пользователя (т.е. студента) с некоторыми из конечных точек well-known спецификации OIDC. Эти well-known конечные точки специфичны для вашего SSO реальма.

Red Hat SSO также предоставляет конечные точки управления реальмом. Несколько из этих конечных точек администрирования реальмов также представлены в этом разделе.

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

. openssl . keytool : (из набора Java Development Kit)

=== OIDC well-known Конечные точки

. Убедитесь, что ссылка:https://stedolan.github.io/jq/[jq] утилита установлена на вашем компьютере.

. Выполните следующее и изучите ответ: +

$ curl -X GET "https://$rhsso_hostname/auth/realms/$rhsso_realm/.well-known/openid-configuration" | python -m json.tool

. Просмотрите список типов grant_types_supported: +

$ curl -X GET "https://$rhsso_hostname/auth/realms/$rhsso_realm/.well-known/openid-configuration" | jq -r '.grant_types_supported'

  • Примерный вывод

[ "authorization_code", "implicit", "refresh_token", "password", "client_credentials" ]

  • Этот список типов grant_type_supported соответствует различным OAuth2/OpenID Connect потокам, поддерживаемым сервером Red Hat SSO.

=== OAuth2 Токен доступа

. Убедитесь, что значения переменных окружения $rhsso_realm, $realmUserId и $realmPasswd установлены в вашей оболочке.

. Получите OIDC Токен доступа из реальма: +

$ retrieve_token_url="https://$rhsso_hostname/auth/realms/$rhsso_realm/protocol/openid-connect/token"

$ TKN=$(curl -X POST "$retrieve_token_url"
-H "Content-Type: application/x-www-form-urlencoded"
-d "username=$SSO_SITE_ADMIN_USERNAME"
-d "password=$SSO_SITE_ADMIN_PASSWORD"
-d "grant_type=password"
-d "client_id=admin-cli"
| sed 's/.access_token":"//g' | sed 's/".//g')

  • ПРИМЕЧАНИЕ: Этот ответ от конечной точки токена OAuth2 можно дополнительно разобрать для получения refresh_token. refresh_token может затем по желанию использоваться для обновления токена доступа, когда токен доступа истекает.

=== Публичный ключ реальма В этом разделе вы получите публичный ключ вашего реальма. Позже, этот публичный ключ можно использовать в адаптере keycloak, который внедряется в бизнес-службу бэкэнда. Служба бэкэнда тогда сможет участвовать в потоке OpenID Connect.

. Когда реальм создается, автоматически генерируется пара ключей и самоподписанный сертификат. + Keycloak в настоящее время поддерживает только RSA подписи, поэтому существует только одна активная пара ключей. . Установите значение переменной окружения $retrieve_key_url: +

$ retrieve_key_url="https://$rhsso_hostname/auth/admin/realms/$rhsso_realm/keys"

. Получите значение RSA ключа: +

$ RSA_PUB_KEY=$(curl -k -X GET "$retrieve_key_url"
-H "Authorization: Bearer $TKN"
| jq -r '.keys[] | select(.type=="RSA") | .publicKey' )

$ echo $RSA_PUB_KEY MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAktETcy8xI/rxit6DH9LW1kAB/0XKiV5eujQL9rL+9WD9ZruC2hMFKhme+kyNjNVCf2cqiY0IChmSqTrfm7OcL3k+Rfq91zDgMI19pszoMGyG2Ek2UZYWNBhydBIPBr70njec7Vq8a/bn88evEROetlUHWWcSuwqsiooHD3RNzuDgRB+2ztim8KttusbZxGPGjIjCNlFEBVetfxpHbTBCeN8dAdOiYRjmW6QVxEUH9m0Hcvcw8XwEyVRvd1HpkzMK0BVBnN73d/G743pvyc2huv/Cj+zoBipxNwKJ8rnPGupBVK/17WmyFgi+CDhZww8EwRiSSwrow+Qv1hUP9bnoFwIDAQAB

=== Дополнительно: Просмотр сертификата RSA реальма

. Получите значение сертификата RSA реальма: +

$ RSA_CERT=$(curl -k -X GET "$retrieve_key_url"
-H "Authorization: Bearer $TKN"
| jq -r '.keys[] | select(.type=="RSA") | .certificate' )

$ echo $RSA_CERT MIICuTCCAaECBgFcJ85oAjANBgkqhkiG9w0BAQsFADAgMR4wHAYDVQQDDBVyaHRfZ3B0ZV8zc2NhbGVfcmVhbG0wHhcNMTcwNTIwMjEzOTE3WhcNMjcwNTIwMjE0MDU3WjAgMR4wHAYDVQQDDBVyaHRfZ3B0ZV8zc2NhbGVfcmVhbG0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCS0RNzLzEj+vGK3oMf0tbWQAH/RcqJXl66NAv2sv71YP1mu4LaEwUqGZ76TI2M1UJ/ZyqJjQgKGZKoGt+bs5wveT5F+r3XMOAwjX2mzOgwbIbYSTZRlhY0GHJ0Eg8GvvSeN5ztWrxr9ufzx68RE562VQdZZxK7CqyKigcPdE3O4OBEH7bO2Kbwq226xtnEY8aMiMI2UUQFV61/GkdtMEJ43x0B06JhGOZbpBXERQf2bQdy9zDxfATJVG93UemTMwrQFUGc3vd38bvjem/JzaG6/8KP7OgGKnE3Aonyuc8a6kFUr/XtabIWCL4IOFnDDwTBGJJLCujD5C/WFQ/1uegXAgMBAAEwDQYJKoZIhvcNAQELBQADggEBABM81ImbVgN5VoD7b7RCH0jYW9pUzIwjUUWU3P1E+RGMwyyhgCwMK/wDpzty5jno7XyE1oePgZg8OmXY2FGlWi0JzCF8WGsHVEZWiKPkSs9miz5+x5VqKUEM4nrmF3OgEFPH/gJPhx8/GNutSpf0AIHcVDeWL7nayyjMZWSdXm82crd5gZXDSmNgjjeqhTCPFCrMv3nQq9wsL3jDEc7pOAkblsu83GCyD0WmdHqAY/EdT/Jz1b2lJw/Oda6b9Hg93MvnnaJMam7Q7q4K0oRFaYD0ZtYm926YQg5f1iLzoocuouuOeHrMfZQOqb96iaGYeQF+GghpfNXwKMLOhQh3tJM=

. Создайте PEM-файл из сертификата: .. Установите переменную окружения, которая определяет путь к целевому x.509 сертификату в формате PEM: +

$ realm_cert=/tmp/$rhsso_realm.pem

.. Создайте x.509 сертификат в формате PEM: +

$ echo "-----BEGIN CERTIFICATE-----" > $realm_cert; echo $RSA_CERT >> $realm_cert; echo "-----END CERTIFICATE-----" >> $realm_cert

. Просмотрите детали сертификата SSO Realm: +

$ openssl x509 -in $realm_cert -text -noout

== Общие реальмы: Тестирование OAuth2 Auth и RBAC

=== Обзор защищенной бизнес-службы

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

ПРИМЕЧАНИЕ: Этот RBAC, управляемый бизнес-сервисом бэкэнда, отличается от политики и лимита частоты, которые обрабатываются API-менеджером.

В этом разделе лаборатории вы протестируете безопасность OAuth2/OIDC с помощью простого сервиса бэкэнда, написанного с использованием технологии link:https://thorntail.io/[Thorntail Java Microprofile].

Исходный код для этого простого сервиса можно найти link:https://github.com/gpe-mw-training/3scale_onpremise_implementation_labs/tree/secure/services/wfswarm-date-service[здесь].

Для того чтобы ваш микропрофильный бизнес-сервис использовал RBAC, необходимо следующее:

  • Интегрировать правила RBAC в бизнес-сервис: Для целей этой лаборатории этот шаг уже выполнен для вас. В частности, обратите внимание на следующий новый фрагмент кода в конфигурационном файле src/main/resources/project-defaults.yml:

swarm: deployment: wf-swarm-oauth.war: web: login-config: auth-method: KEYCLOAK security-constraints: - url-pattern: / methods: [GET] roles: [admin]

  • Добавить адаптер Keycloak: Вашему бизнес-сервису бэкэнда необходимо внедрить функциональность, позволяющую ему взаимодействовать с сервером Red Hat SSO. В частности, ему необходимо запрашивать публичный ключ реальма сервера Red Hat SSO.

  • Расшифровать JWT с помощью публичного ключа реальма Red Hat SSO: В момент выполнения бизнес-сервису бэкэнда передается токен JSON Web Token (JWT) с идентификационной информацией о конечном пользователе. Эта идентификационная информация включает в себя роль конечного пользователя. После получения JWT встроенный адаптер Keycloak проверяет подлинность JWT (с использованием публичного ключа реальма Red Hat SSO). После того как JWT подтверждается как исходящий от вашего сервера Red Hat SSO, бизнес-сервис использует идентификационную информацию, чтобы определить, имеет ли конечный пользователь правильные полномочия для доступа к запрашиваемому ресурсу.

=== Развертывание В этом разделе вы определите DeploymentConfig для простой бизнес-службы бэкэнда, которая должна быть защищена с помощью протокола OIDC.

. Создайте новый проект для ваших экспериментов с приложениями RESTful-сервисов: +

$ oc new-project $OCP_PROJECT_PREFIX-bservices
--display-name="$OCP_PROJECT_PREFIX-bservices"
--description="Бизнес-сервисы для защиты с использованием OIDC"

. Если вы еще не сделали этого, переключитесь на этот новый проект: +

$ oc project $OCP_PROJECT_PREFIX-bservices

. Создайте новое приложение на основе простого RESTful сервиса, реализованного с использованием Wildfly Swarm: +

$ oc create -f https://raw.githubusercontent.com/gpe-mw-training/3scale_onpremise_implementation_labs/secure/services/wfswarm-date-service/wf-swarm-oauth.yaml

$ oc new-app
--template=wf-swarm-oauth
--param=JAVA_OPTIONS="-Djavax.net.debug=ssl -Dswarm.keycloak.json.path=/app/rhsso-config/keycloak.json"

  • Эта команда создает конфигурацию развертывания с приостановленным подом. Под включает контейнер на основе Java. Параметр --XmX JVM контейнера установлен на 80% от 1 Gi; т.е. приблизительно 800 МБ.

=== keycloak.json адаптер

. Определите адаптер keycloak, специфичный для существующего клиента bearer-only, называемого: realm-management: +

$ echo " { "realm": "$rhsso_realm", "bearer-only": "true", "auth-server-url": "http://$rhsso_hostname/auth", "ssl-required": "external", "realm-public-key": "$RSA_PUB_KEY", "resource": "realm-management", "use-resource-role-mappings": "true" }" > /tmp/keycloak.json

. Создайте ConfigMap из файла keycloak.json. + Затем вы монтируете его в качестве тома и указываете WildFly Swarm на смонтированный keycloak.json.

.. Создайте ConfigMap с именем date-service-rhsso в проекте bservices на OpenShift из файла keycloak.json: +

$ oc create configmap keycloak-resource-cm --from-file=/tmp/keycloak.json

.. Монтируйте этот configmap как том в DC Swarm: +

$ oc set volume dc/wf-swarm-oauth --add --overwrite
--name=keycloak-resource-volume
-m /app/rhsso-config
--type=configmap
--configmap-name=keycloak-resource-cm

. Возобновите приостановленное развертывание: +

$ oc rollout resume dc/wf-swarm-oauth

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

DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) KeycloakServletException инициализация DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) используется /WEB-INF/keycloak.json DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Используется поставщик 'secret' для аутентификации клиента 'realm-management' DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Загрузка секрета провайдера clientCredentialsProvider DEBUG [org.keycloak.adapters.authentication.ClientCredentialsProviderUtils] (ServerService Thread Pool -- 11) Загрузка jwt провайдера clientCredentialsProvider DEBUG [org.keycloak.adapters.KeycloakDeployment] (ServerService Thread Pool -- 11) resolveUrls DEBUG [org.keycloak.adapters.KeycloakDeploymentBuilder] (ServerService Thread Pool -- 11) Используйте authServerUrl: https://sso-rhsso-sso0.apps.3295.openshift.opentlc.com/auth, tokenUrl: https://sso-rhsso-sso0.apps.3295.openshift.opentlc.com/auth/realms/realm1/protocol/openid-connect/token, relativeUrls: NEVER DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Keycloak использует конфигурацию для каждого развертывания. DEBUG [org.keycloak.adapters.wildfly.WildflyKeycloakServletExtension] (ServerService Thread Pool -- 11) создание WildflyAuthenticationMechanism DEBUG [org.keycloak.adapters.undertow.KeycloakServletExtension] (ServerService Thread Pool -- 11) Установить путь для jsession cookie: /

... INFO [org.wildfly.swarm] (main) WFSWARM99999: WildFly Swarm готов

=== Тестирование OAuth2 защищенной бизнес-службы:

. Выполните следующее, чтобы получить новый токен доступа (поскольку оригинальный токен доступа, вероятно, истек): +

$ TKN=$(curl -k -X POST "$retrieve_token_url"
-H "Content-Type: application/x-www-form-urlencoded"
-d "username=$realmUserId"
-d "password=$realmPasswd"
-d "grant_type=password"
-d "client_id=admin-cli"
| sed 's/.access_token":"//g' | sed 's/".//g')

  • В идеале, лучший подход заключается в использовании функции refresh_token OAuth2 вместо повторного создания нового токена доступа. При этом следует указывать параметры grant_type=refresh_token&refresh_token=$REFRESH_TOKEN в теле запроса. Значение $REFRESH_TOKEN можно было бы получить, разобрав его из ответа оригинального запроса на токены OAuth2.

. Выполните следующее, чтобы вызвать защищенную RESTful службу с использованием токена доступа OAUTH2: +

$ curl -k -v -X GET
-H "Authorization: Bearer $TKN"
https://oc get route/wf-swarm-oauth --template "{{.spec.host}}"/time/now

. Ответ должен включать заголовки и тело, подобные следующему: +

...

  • TLSv1.2 (IN), TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
  • ALPN, server did not agree to a protocol
  • Server certificate:
  • subject: CN=master.3295.openshift.opentlc.com
  • start date: Nov 13 20:48:38 2018 GMT
  • expire date: Feb 11 20:48:38 2019 GMT
  • issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
  • SSL certificate verify ok.

    GET /time/now HTTP/1.1 Host: wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com User-Agent: curl/7.61.1 Accept: / Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJIbm5ZV1NMM1pqSTh0T0VHZVlWZHpIbXVVSFpYSDdJbHM1dEJkSVU0VHMwIn0.eyJqdGkiOiIwOWQyZDZhMC1kZmRjLTRjNTctOWZjOC1mMDVjZGU0MjFjMjAiLCJleHAiOjE1NDIyMTQwMzYsIm5iZiI6MCwiaWF0IjoxNTQyMjEzNzM2LCJpc3MiOiJodHRwczovL3Nzby1yaHNzby1zc28wLmFwcHMuMzI5NS5vcGVuc2hpZnQub3BlbnRsYy5jb20vYXV0aC9yZWFsbXMvcmVhbG0xIiwiYXVkIjoiYWRtaW4tY2xpIiwic3ViIjoiNDc2Y2ZlOTAtMTQwMC00ODUwLTg5M2YtNjNlNWM5MjFmMjYxIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoiYWRtaW4tY2xpIiwiYXV0aF90aW1lIjowLCJzZXNzaW9uX3N0YXRlIjoiNmQ2ODcyZjgtMjQwZC00MWVjLWE4NmQtM2FiOGEyZTVmZWE5IiwiYWNyIjoiMSIsImFsbG93ZWQtb3JpZ2lucyI6W10sInJlc291cmNlX2FjY2VzcyI6e30sIm5hbWUiOiJKZWZmIEJyaWRlIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiamJyaWRlIiwiZ2l2ZW5fbmFtZSI6IkplZmYiLCJmYW1pbHlfbmFtZSI6IkJyaWRlIiwiZW1haWwiOiJqYnJpZGUrMUByZWRoYXQuY29tIn0.PoqUaPncOt9GFpCdHTQE1zuVK3FHTrgkBhmthww9geM-pbV84UTLXr1ggD-v7s9DGYAaVTe7ZUcda0DT5ioADpPuik6qADPf0ZkkWGQiQ6aieBxuTikM0NeeM58Vwhcr5lDphD0VY70SK_aaevUKkZFkmKxUxeUj-8TZob0n5Jip376D8NvDtfoZEhiWngBW58H1J4-sg27qzaUgVqaEoM7zUEvZocgD6j6rUqnThNREJVMi3sUYli6y_LzzqrMwZrWTlxAIYcR6OQ7GK-WTtN_F18_5O28Zaojq1QRHjhotcHPXCTrJaf4XqNEZFGML8yVh5lgzd-HVMt3Lrd_15Q

    < HTTP/1.1 200 OK

...

{"value" : "The time is 2018-11-14T16:44:57.576Z"}

. Проверьте файл журнала защищенной службы WildFly Swarm. Журнал должен содержать записи, похожие на следующие: +

DEBUG [org.keycloak.adapters.PreAuthActionsHandler] (default task-1) adminRequest http://wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com/time/now DEBUG [org.keycloak.adapters.wildfly.WildflyRequestAuthenticator] (default task-1) propagate security context to wildfly DEBUG [org.keycloak.adapters.RequestAuthenticator] (default task-1) User '476cfe90-1400-4850-893f-63e5c921f261' invoking 'http://wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com/time/now' on client 'realm-management' DEBUG [org.keycloak.adapters.RequestAuthenticator] (default task-1) Bearer AUTHENTICATED DEBUG [org.keycloak.adapters.AuthenticatedActionsHandler] (default task-1) AuthenticatedActionsValve.invoke http://wf-swarm-oauth-jb-bservices.apps.3295.openshift.opentlc.com/time/now DEBUG [org.keycloak.adapters.AuthenticatedActionsHandler] (default task-1) Policy enforcement is disabled. INFO [stdout] (default task-1) userId = 476cfe90-1400-4850-893f-63e5c921f261

== Приложение

=== Установить уровень логирования RH-SSO на DEBUG (по желанию)

Иногда вы можете захотеть увеличить уровень логирования пакета java org.keycloak вашего сервера RH-SSO с INFO на DEBUG. Это полезно, когда вы пытаетесь устранить неполадки с проблемами безопасности и RH-SSO.

. Откройте удаленную сессию оболочки к вашему поду RH-SSO: +

$ oc rsh -n $rhsso_project
$(oc get под -n $rhsso_project | egrep "sso-[1-9]" | awk '{print $1}')

. Отредактируйте главный конфигурационный файл вашего сервера RH-SSO: .. Откройте конфигурационный файл в редакторе: +

$ vi /opt/eap/standalone/configuration/standalone-openshift.xml

.. Найдите поле org.jboss.as.config: +

        <logger category="org.jboss.as.config">
            <level name="DEBUG"/>
        </logger>

.. Чуть ниже этого блока XML добавьте аналогичный блок, как показано ниже: +

        <logger category="org.keycloak">
            <level name="DEBUG"/>
        </logger>

.. Сохраните изменения и выйдите.

. Перезапустите JVM keycloak в том же поде RH-SSO: .. Перейдите в следующий каталог: +

cd /opt/eap/bin/

.. Выполните эту команду: +

./jboss-cli.sh --connect ':reload'

О проекте

Red Hat Single Sign-On Multi-Realm Automated Provisioning

role identityprovider oauth2 oidc rhsso
Установить
ansible-galaxy install gpe-mw-ansible-org/rh-sso-multi-realm
GitHub репозиторий
0 звезд(ы)
2 форк(ов)
8 открытых задач
Лицензия
Unknown
Загрузки
80
Владелец
gpe-mw-ansible-org
Ansible roles to support RHT middleware labs