Как изменить URL-адрес аутентификации, сгенерированный Java-адаптером Keycloak OpenID Connect?

Question

Мы используем Keycloak Java адаптер 4.5.0 в сочетании с EAP7.1. Когда мы настраиваем наш keycloak.json, мы имеем для auth-server-url URL https://authentication.country.com/op/v1/auth, Все идет нормально.

Когда мы перейдем к нашему приложению, мы будем перенаправлены на https://authentication.country.com/op/v1/auth/realms/KeycloakOIDCRealm/protocol/openid-connect/auth?response_type=code&client_id=fac9d161-d27d-493d-uze896zed78&redirect_uri=....,

Это не хорошо, так как мы используем нашего собственного провайдера идентификации. Удаление realms/KeycloakOIDCRealm/protocol/openid-connect/ часть URL-адреса, правильно передает его поставщику удостоверений. Поэтому адаптер Keycloak добавляет его по умолчанию, при условии, что мы всегда будем использовать Keycloak в качестве поставщика удостоверений. До того, как мы использовали SAML, у нас не было этой проблемы.

Как мы можем настроить keycloak.json для адаптера, чтобы исключить добавление realms/KeycloakOIDCRealm/protocol/openid-connect/?

Answer 1

Я связался со службой поддержки Keycloak, и они ответили следующим образом:

Привет Фабрицио,

Действительно, строковые шаблоны, такие как "/realms/{realm-name}/protocol/openid-connect/auth", жестко запрограммированы в адаптеры Keycloak.

К счастью, кажется, что есть обходной путь. В Keycloak есть механизм для нескольких арендаторов; для этого требуется предоставить средство распознавания, которое будет возвращать экземпляр KeycloakDeployment на основе параметров запроса. Одна из его дополнительных функций заключается в том, что вы можете полностью переопределить поведение KeycloakDeployment. Например, вы можете расширить org.keycloak.adapters.KeycloakDeployment и переопределить его метод resolUrls(), чтобы URL-адреса указывали на ваш сторонний IDP.

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

Другой вариант - установить промежуточный Keycloak (сервер), настроить посредничество для стороннего IDP и указать свой адаптер на Keycloak. Хотя это звучит как перебор, это пуленепробиваемое решение, которое должно работать на 100% (и у него также есть некоторые другие преимущества).

Конечно, есть и другие варианты, такие как использование эквивалента стороннего IDP для адаптера Keycloak, использование других библиотек Java OpenID Connect или даже адаптеров уровня прокси, таких как apache-mod_auth_openidc или Keycloak Gatekeeper. Но я понимаю, что это, вероятно, потребует переписывания кода, поэтому вы должны рассматривать эти опции только как последнее средство.

Что касается SAML и почему он раньше работал: Адаптер Keycloak использует стандартные метаданные SAML SP для конфигурации, которая строго и однозначно определяет URL; здесь мы должны признать, что SAML более зрелый и функциональный.

OIDC, напротив, допускает некоторую свободу. В настоящее время адаптер Keycloak OIDC не использует стандартные метаданные, а генерирует URL-адреса с использованием жестко закодированных шаблонов. Я думаю, что адаптер Keycloak мог бы использовать грубый эквивалент OIDC для метаданных SAML, а именно "известные" URL-адреса.

Теоретически, OIDC-адаптер Keycloak может использовать эти метаданные вместо шаблонов URL с жестким кодированием. Для меня это может быть ценным дополнением, но удивительно, я не вижу никакой связанной с JIRA проблемы. Возможно, разработчики Keycloak могли бы дать нам некоторую обратную связь.

Я обновлю этот ответ, если будет билет Jira для использования метаданных вместо жестко закодированных шаблонов.