Keycloak SSO Интеграция в jBPM и Drools Workbench

Вступление

Единый вход в систему (SSO) и связанные с ним механизмы обмена токенами становятся наиболее распространенным сценарием для аутентификации и авторизации в различных средах в Интернете, особенно при переходе в облако.

В этой статье рассказывается об интеграции Keycloak с приложениями jBPM или Drools, чтобы использовать все функции, предоставляемые в Keycloak. Keycloak — это интегрированный SSO и IDM для браузерных приложений и веб-сервисов RESTful. Узнайте больше об этом на домашней странице Keycloak .

Результат интеграции с Keycloak имеет много преимуществ, таких как:

• Предоставить интегрированную среду единого входа и среды IDM для разных клиентов, включая рабочие места jBPM и Drools
• Социальные логины — используйте учетные записи Facebook, Google, Linkedin и т. Д.
• Управление сессиями пользователей
• И многое другое…

В следующих разделах рассматриваются следующие моменты интеграции с Keycloak:

• Аутентификация Workbench через сервер Keycloak : в основном она состоит из защиты как веб-клиента, так и клиентов удаленного обслуживания через Keycloak SSO. Таким образом, либо веб-интерфейс, либо пользователи удаленного сервиса (будь то пользователь или сервис) будут проходить аутентификацию в KC.
• Аутентификация сервера выполнения через сервер Keycloak : состоит из защиты удаленных служб, предоставляемых сервером выполнения (так как он не предоставляет веб-интерфейс). Любой потребитель удаленного сервиса (будь то пользователь или сервис) будет аутентифицироваться через KC.
• Использование удаленных служб . В этом разделе описывается, как сторонние клиенты могут использовать конечные точки удаленных служб, предоставляемые как Workbench, так и Execution Server.

сценарий

Рассмотрим следующую диаграмму в качестве среды для примера этой статьи:

Keycloak — это автономный процесс, который предоставляет услуги удаленной аутентификации, авторизации и администрирования, которые могут потенциально использоваться одним или несколькими приложениями jBPM по сети.

Рассмотрим следующие основные шаги для построения этой среды:

• Установите и настройте сервер Keycloak
• Создайте и настройте область для этого примера — настройте клиентов, пользователей и роли области
• Установите и настройте клиентский адаптер SSO и приложение jBPM

Заметки:

• Результирующая среда и различные конфигурации для этой статьи основаны на инструментальных средствах jBPM (KIE), но те же самые могут также применяться к KIE Drools Workbench.
• В этом примере используется последняя версия релиза сообщества 6.4.0.CR2 .

Шаг 1 — Установите и настройте сервер Keycloak

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

Вот шаги для минимальной установки и настройки Keycloak:

1. Загрузите последнюю версию Keycloak из раздела « Загрузки ». Этот пример основан на Keycloak 1.9.0.Final.
2. Распакуйте загруженный дистрибутив Keycloak в папку, давайте $KC_HOME его $KC_HOME
3. Запустить сервер KC — этот пример основан на запуске Keycloak и jBPM на одном хосте. Чтобы избежать конфликтов портов, вы можете использовать смещение порта для сервера Keycloak как:

   1	$KC_HOME/bin/standalone.sh -Djboss.socket.binding.port-offset=100

4. Создайте пользователя-администратора Keycloak — выполните следующую команду, чтобы создать пользователя-администратора для этого примера:

   1	$KC_HOME/bin/add-user.sh -r master -u 'admin' -p 'admin'

Консоль администрирования Keycloak будет доступна по адресу http: // localhost: 8180 / auth / admin (используйте admin / admin для учетных данных для входа).

Шаг 2 — Создание и настройка демо-области

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

Когда сервер Keycloak запущен, следующим шагом будет создание области. В этой области будут представлены разные пользователи, роли, сеансы и т. Д. Для приложений jBPM.

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

Вы можете создать область вручную или просто импортировать данные файлы JSON.

Создание области шаг за шагом

Выполните эти шаги для создания демонстрационной области, используемой позже в этой статье:

1. Перейдите в консоль администрирования Keycloak и нажмите кнопку Добавить область . Дайте ему название демо .
2. Перейдите в раздел «Клиенты» (из главного меню консоли администратора) и создайте нового клиента для демо- области:
   • Идентификатор клиента: kie
   • Клиентский протокол: openid-connect
   • Тип доступа: конфиденциальный
   • Корневой URL: http: // localhost: 8080
   • Базовый URL: /kie-wb-6.4.0.Final
   • URI перенаправления: /kie-wb-6.4.0.Final/*

Получившийся экран настроек клиента kie :

Примечание . Как видно из приведенных выше настроек, оно считается значением kie-wb-6.4.0.Final для пути к контексту приложения. Если ваше приложение jbpm будет развернуто по другому пути контекста, хосту или порту, просто используйте ваши конкретные настройки здесь.

Последний шаг для возможности использования демонстрационной области из рабочей среды jBPM — создание пользователя и ролей приложения:

• Перейдите в раздел Роли и создайте роли admin , kiemgmt и rest-all .
• Перейдите в раздел «Пользователи» и создайте пользователя- администратора . Установите пароль со значением «пароль» на вкладке учетных данных, сбросьте временный переключатель.
• В разделе «Пользователи» перейдите на вкладку « Сопоставление ролей » и назначьте роли admin, kiemgmt и rest-all пользователю- администратору.

Импорт демо-области

Импортируйте оба:

• Демо-область — нажмите Добавить область и используйте файл demo-realm.json
• Пользователи области — После импорта демо-области нажмите кнопку « Импорт» в главном меню и используйте файл demo-users-0.json в качестве источника импорта.

В этот момент на хосте работает сервер Keycloak с минимальным набором настроек. Давайте перейдем к настройке рабочего места jBPM.

Шаг 3 — Установите и настройте рабочую среду jBPM

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

Предположим, что после запуска установщика jBPM $ JBPM_HOME является корневым путем для сервера Wildfly, на котором было развернуто приложение.

Шаг 3.1 — Установите адаптер KC

Чтобы использовать модули аутентификации и авторизации Keycloak из приложения jBPM, адаптер Keycloak для Wildfly должен быть установлен на нашем сервере по адресу $ JBPM_HOME . Keycloak предоставляет несколько адаптеров для разных контейнеров из коробки, если вы используете другой контейнер или вам нужен другой адаптер, пожалуйста, ознакомьтесь с конфигурацией адаптеров из документации Keycloak. Вот шаги по установке и настройке адаптера для Wildfly 8.2.x:

1. Загрузите адаптер отсюда
2. Выполните следующие команды:

   1 2 3 4 5 6 7 8 9

   cd $JBPM_HOME/ unzip keycloak-wf8-adapter-dist.zip // Install the KC client adapter   cd $JBPM_HOME/bin ./standalone.sh -c standalone-full.xml // Setup the KC client adapter.   // ** Once server is up, open a new command line terminal and run: cd $JBPM_HOME/bin ./jboss-cli.sh -c --file=adapter-install.cli

Шаг 3.2 — Настройка адаптера KC

После установки адаптера KC в Wildfly, следующий шаг — настроить адаптер, чтобы указать различные параметры, такие как местоположение сервера аутентификации, область использования и т. Д.

Keycloak предоставляет два способа настройки адаптера:

• В конфигурации WAR
• Через подсистему Keycloak

В этом примере давайте воспользуемся вторым вариантом, используем подсистему Keycloak, чтобы наша WAR была свободна от таких настроек. Если вы хотите использовать подход «per WAR», посмотрите здесь .

Отредактируйте файл конфигурации $ JBPM_HOME / standalone / configuration / standalone-full.xml и найдите раздел конфигурации подсистемы. Добавьте следующий контент:

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

• Имя для безопасного развертывания — используйте имя WAR-файла вашего конкретного приложения
• Область — Область, которую приложения будут использовать, в нашем примере, область демонстрации, созданная на шаге 2.
• Открытый ключ Realm — предоставьте здесь открытый ключ для демо- области. Это не обязательно, если оно не указано, оно будет получено с сервера. В противном случае вы можете найти его в консоли администратора Keycloak -> Настройки области (для демо- области) -> Ключи
• URL-адрес сервера аутентификации — URL-адрес сервера аутентификации Keycloak
• Ресурс — имя для клиента, созданное на шаге 2. В нашем примере используйте значение kie .
• Включить базовую аутентификацию — для этого примера давайте также включим механизм базовой аутентификации, чтобы клиенты могли использовать подходы Token (Baerer) и Basic для выполнения запросов.
• Учетные данные — используйте значение пароля для клиента kie . Вы можете найти его в консоли администратора Keycloak -> Клиенты -> kie -> вкладка Credentials -> Скопировать значение секрета .

В этом примере вы должны позаботиться об использовании ваших конкретных значений для имени безопасного развертывания , realm-public-key и пароля для доступа. Вы можете найти подробную информацию о конфигурации адаптера KC здесь .

Шаг 3.3 — Запустите среду

На этом этапе сервер Keycloak запущен и работает на хосте, а адаптер KC установлен и настроен для сервера приложений jBPM. Вы можете запустить приложение, используя:

После запуска сервера вы можете перейти в приложение по адресу: http: // localhost: 8080 / kie-wb-6.4.0.Final

Используйте учетные данные администратора Keycloak для входа в систему: admin / пароль

Защита удаленных сервисов рабочей среды через Keycloak

Рабочие среды jBPM и Drools предоставляют разные конечные точки удаленного обслуживания, которые могут использоваться сторонними клиентами с помощью удаленного API .

Чтобы полностью проверить подлинность этих служб Keycloak, BasicAuthSecurityFilter должен быть отключен, примените эти изменения для файла WEB-INF / web.xml (дескриптор развертывания приложения) из файла WAR jBPM:

1. Удалить фильтр:

   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15

   < filter > <filter-name>HTTP Basic Auth Filter</filter-name>   <filter-class>org.uberfire.ext.security.server.BasicAuthSecurityFilter</filter-class>   <init-param>     <param-name>realmName</param-name>     <param-value>KIE Workbench Realm</param-value>   </init-param> </filter>   <filter-mapping>   <filter-name>HTTP Basic Auth Filter</filter-name>   <url-pattern>/rest/*</url-pattern>   <url-pattern>/maven2/*</url-pattern>   <url-pattern>/ws/*</url-pattern> </filter-mapping>

2. Ограничьте шаблоны URL удаленных сервисов как:

   01 02 03 04 05 06 07 08 09 10 11

   <security-constraint>   <web-resource-collection>     <web-resource-name>remote-services</web-resource-name>     <url-pattern>/rest/*</url-pattern>     <url-pattern>/maven2/*</url-pattern>     <url-pattern>/ws/*</url-pattern>   </web-resource-collection>   <auth-constraint>     <role-name>rest-all</role-name>   </auth-constraint> </security-constraint>

Важное примечание : пользователь, который использует удаленные службы, должен быть членом роли rest-all . Как описано в шаге 2, пользователь с правами администратора в этом примере уже является членом роли rest-all .

Исполнительный сервер

Сервер выполнения KIE предоставляет API REST, который может использоваться любыми сторонними клиентами. В этом разделе рассказывается, как интегрировать KIE Execution Server с SSO Keycloak, чтобы делегировать управление идентификацией сторонних клиентов серверу SSO.

Рассмотрим вышеописанную работающую среду, поэтому подумайте о том, чтобы:

• Сервер Keycloak работает и прослушивает http: // localhost: 8180 / auth
• Область с именем demo с клиентом kie для jBPM Workbench
• Рабочая среда jBPM, работающая по адресу http: // localhost: 8080 / kie-wb-6.4.0-Final

Выполните эти шаги для добавления сервера выполнения в эту среду:

• Создайте клиент для исполнительного сервера на Keycloak
• Установите установку и Сервер выполнения (с адаптером клиента KC)

Шаг 1 — Создайте клиент для исполнительного сервера на Keycloak

В соответствии с каждым сервером выполнения, который вы собираетесь развернуть, вы должны создать нового клиента в демо- области в Keycloak.

1. Зайдите в консоль администратора KC -> Клиенты -> Новый клиент
2. Название: kie-исполнительный сервер
3. Корневой URL: http: // localhost: 8280 /
4. Клиентский протокол: openid-connect
5. Тип доступа: конфиденциальный (или публичный, если вы хотите, но не рекомендуется)
6. Допустимые URI перенаправления: /kie-server-6.4.0.Final/*
7. Базовый URL: /kie-server-6.4.0.Final

В этом примере пользователь admin, уже созданный на предыдущих шагах, является тем, который используется для клиентских запросов. Поэтому убедитесь, что пользователь admin является членом роли kie-server , чтобы использовать удаленные сервисы исполнительного сервера. Если роль не существует, создайте ее.

Примечание. В этом примере показано, что исполнительный сервер будет настроен на работу с использованием смещения порта 200, поэтому порт HTTP будет доступен по адресу localhost: 8280.

Шаг 2 — Установите и настройте клиентский адаптер KC и сервер выполнения

На этом этапе клиент с именем kie-исполнительный сервер готов на сервере KC использовать с исполнительного сервера. Давайте установим, настроим и развернем исполнительный сервер:

1. Установите другой сервер Wildfly, чтобы использовать его для исполнительного сервера и клиентского адаптера KC. Вы можете следовать приведенным выше инструкциям для Workbench или следовать официальной документации по адаптерам .
2. Отредактируйте файл standalone-full.xml из пути конфигурации сервера Wildfly и настройте адаптер подсистемы KC следующим образом:

   01 02 03 04 05 06 07 08 09 10 11 12

   <secure-deployment name="kie-server-6.4.0.Final.war">     <realm>demo</realm>     <realm-public-key>         MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrVrCuTtArbgaZzL1hvh0xtL5mc7o0NqPVnYXkLvgcwiC3BjLGw1tGEGoJaXDuSaRllobm53JBhjx33UNv+5z/UMG4kytBWxheNVKnL6GgqlNabMaFfPLPCF8kAgKnsi79NMo+n6KnSY8YeUmec/p2vjO2NjsSAVcWEQMVhJ31LwIDAQAB     </realm-public-key>     <auth-server-url>http://localhost:8180/auth</auth-server-url>     <ssl-required>external</ssl-required>     <resource>kie-execution-server</resource>     <enable-basic-auth>true</enable-basic-auth>     <credential name="secret">e92ec68d-6177-4239-be05-28ef2f3460ff</credential>     <principal-attribute>preferred_username</principal-attribute> </secure-deployment>

Рассмотрите ваши конкретные настройки среды, если они отличаются от этого примера:

• Имя защищенного развертывания -> использовать имя развертываемого файла боевого сервера выполнения.
• Открытый ключ -> Используйте открытый ключ демо-области или оставьте его пустым, сервер предоставит его, если так
• Ресурс -> На этот раз вместо клиента kie, используемого в конфигурации WB, используйте клиент kie-execute-server
• Включить базовую авторизацию -> до вас. Вы можете включить базовую аутентификацию для сторонних потребителей услуг
• Credential -> Использовать секретный ключ для клиента kie-исполнительного сервера . Вы можете найти его на вкладке Credentials консоли администратора KC.

Шаг 3 — Разверните и запустите сервер выполнения

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

Запустите исполнительный сервер с помощью этой команды:

Пример:

Важное примечание . Пользователям, которые будут использовать конечные точки удаленного сервиса исполнительного сервера, должна быть назначена роль kie-server. Поэтому создайте и назначьте эту роль в консоли администратора KC для пользователей, которые будут использовать удаленные службы исполнительного сервера.

После этого вы можете проверить состояние сервера как (рассмотрено использование обычной аутентификации для этого запроса, см. Далее Использование удаленных служб для получения дополнительной информации):

Использование удаленных сервисов

Чтобы использовать различные удаленные службы, предоставляемые Workbench или Execution Server, ваш клиент должен пройти проверку подлинности на сервере KC и иметь действительный токен для выполнения запросов.

ПРИМЕЧАНИЕ . Помните, что для использования удаленных служб аутентифицированный пользователь должен назначить:

• Роль rest-all для использования удаленных сервисов WB
• Роль kie-server для использования удаленных сервисов Execution Server

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

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

• Использование базовой аутентификации, если клиент приложения поддерживает ее
• Использование аутентификации на основе носителя (токена)

Использование базовой аутентификации

Если в конфигурации клиентского адаптера KC включена обычная проверка подлинности, как предлагается в этом руководстве как для WB ( шаг 3.2 ), так и для Execution Server, вы можете избежать вызовов предоставления / обновления токена и просто вызвать службы в следующих примерах.

Пример для конечной точки удаленных репозиториев WB:

Пример для проверки состояния сервера выполнения:

Использование аутентификации на основе токенов

Первым шагом является создание нового клиента на Keycloak, который позволяет сторонним клиентам удаленного обслуживания получать токен. Это можно сделать как:

• Перейдите в консоль администратора KC и создайте новый клиент, используя эту конфигурацию:
  • Идентификатор клиента: kie-remote
  • Клиентский протокол: openid-connect
  • Тип доступа: публичный
  • Действительные URI перенаправления: http: // localhost /
    
• Поскольку мы собираемся вручную получить токен и вызвать службу, давайте немного увеличим срок службы токенов. В производстве токены доступа должны иметь относительно небольшой тайм-аут, в идеале менее 5 минут:
  • Перейти к консоли администратора KC
  • Нажмите на свои настройки области
  • Нажмите на вкладку Жетоны
  • Измените значение срока действия Access Token на 15 минут (это должно дать нам достаточно времени для получения токена и вызова службы до истечения срока ее действия).

После создания общедоступного клиента для наших удаленных клиентов вы можете получить токен, выполнив HTTP-запрос к конечной точке токенов сервера KC. Вот пример для командной строки:

На этом этапе, если вы отобразите $ TOKEN, он выведет строку токена, полученную с сервера KC, которая теперь может использоваться для авторизации дальнейших вызовов к удаленным конечным точкам. Например, если вы хотите проверить внутренние репозитории jBPM: