Как изменить URL-адрес аутентификации, сгенерированный Java-адаптером Keycloak OpenID Connect? - PullRequest
0 голосов
/ 07 ноября 2018

Мы используем 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=.....

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

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

1 Ответ

0 голосов
/ 23 ноября 2018

Я связался со службой поддержки 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 для использования метаданных вместо жестко закодированных шаблонов.

...