2017-01-17 5 views
1

В настоящее время мы разрабатываем приложение для микросервиса с использованием Spring Boot 1.4 и Keycloak 2.5.0 (настроено как служба openid-connect) с использованием адаптера Spring Keycloak (а не Весенний адаптер).Как интегрировать keycloak в Spring Boot с другим корнем и обратным прокси-сервером

Все наши microservices ставятся позади балансировки нагрузки и дополнительного обратного прокси-сервера, как приложение будет размещен на существующем домене позади контекста корня (так корень нашего приложения http://foo.bar/foobar/ и остальные услуги http://foo.bar/foobar/rest/).

Мы столкнулись с парой проблем с Keycloak в этом данном сценарии:

  1. Keycloak вперед/SSO/входа в систему, если требуется знак в. Это в нашем случае нежелательное поведение, потому что http://foo.bar/sso/login не будет существовать. Я нашел способ изменить форвард, но нет способа заставить Keycloak прослушивать один и тот же URL-адрес; в этом случае мы получим 404.
  2. После входа в систему Keycloak перенаправляет обратно в URL-адрес/sso/login с правильными токенами, но если это не тот же сервер, запрос завершается с ошибкой и перенаправляет нас на http://foo.bar/. Поскольку каждый микросервис предоставляет/sso/login, это может быть фактически совершенно другой сервер.
  3. Если keycloak размещен в том же домене, мы закончим цикл перенаправления. Мы также хотели бы, чтобы Keycloak размещался в том же домене и в корне контекста http://foo.bar/foobar/auth/.

Мы уже пробовали использовать "token-store": "cookie", но это не решило проблему.

Есть ли способ решить эти проблемы или это Keycloak, возможно, не правильное решение для нашего прецедента?


Update 05/05/2017: Переместить мой ответ здесь в ответ

+0

Другая проблема заключается в том, что после аутентификации мы перенаправляемся непосредственно на наш сервер, поэтому вместо этого перейдите на http://foo.bar/foobar/rest/service, мы перенаправляемся на http: // localhost: 8080/rest/service –

+0

Эй, я столкнулся с той же проблемой, и я разрешил ее, используя аналогичную конфигурацию , Не могли бы вы добавить свое решение в качестве ответа и проверить этот вопрос как разрешенный? Будет легче увидеть, что делать для следующего, читающего это. – Ruben

+0

Хорошо, переложил его на ответ. Если ваше решение было каким-то иным образом, можете ли вы также указать его? –

ответ

1

Мы сейчас и работает с Keycloak поэтому я кратко объясню, что мы сделали. В интерфейсе нашего приложения работает Angular2, и мы создали пользовательскую страницу входа в само приложение Angular (так что это не тема для Keycloak), которая будет напрямую запрашивать API Keycloak для токена-маркера OAuth2. Передняя часть отправит этот токен по каждому запросу в заголовке авторизации (в соответствии со стандартами OAuth). На стороне обслуживания мы сконфигурировали keycloak как решение только для канала (bearer-only: true в keycloak.json), таким образом приложение просто возвращает 401 или 403 вместо пересылки на страницу входа.

Используя эту конфигурацию, пользователь никогда ничего не увидит на странице/sso/login, и проблема с перенаправлением также больше не будет.

TLDR; описанный прецедентом, также не был реалистичным, вызывая URL-адрес REST, а затем пересылать на страницу входа в систему - это плохой материал :)