Keycloak .well-known / openid-configuration не отвечает протоколом «https» для конечных точек - PullRequest
Новая
       34

Keycloak .well-known / openid-configuration не отвечает протоколом «https» для конечных точек

0 голосов
/ 26 апреля 2018

Мы развернули Keycloak за балансировщиком нагрузки F5. Клиенты OIDC, находящиеся в публичной сети, используют «https» для всех коммуникаций. SSL завершается в F5, и пакеты пересылаются в Keycloak (скажем, на порт 8080).
Клиент OIDC разработан таким образом, чтобы использовать конечные точки (например, /token и т. Д.), Которые он получает в ответе на запрос .well-known/openid-configuration.

Проблема здесь в том, что конфиг .well-known отвечает URL-адресами с протоколом как http для всех конечных точек, где клиент ожидает протокол с https. Из-за этого клиент не может сделать безопасное соединение с этими URL-адресами.

Вопрос в том, как мы можем получить ответы на запрос возврата .well-known/openid-configuration с конечными точками с протоколом https; как упомянутое ниже 

{
  "issuer":"https://<domain>/auth/realms/master",
  "authorization_endpoint":"https://<domain>/auth/realms/master/protocol/openid-connect/auth",
  "token_endpoint":"https://<domain>/auth/realms/master/protocol/openid-connect/token"
  .......
}

Мы выполнили шаги, упомянутые в документации .

Т.е. в F5 были добавлены x-Forwarded-For и x-Forwarded-Proto и внесены соответствующие изменения конфигурации клавиатуры, как указано в документации. Есть ли какие-либо настройки или настройки, которые я мог бы пропустить?

Ответы [ 2 ]

0 голосов
/ 13 сентября 2018

Я боролся с той же проблемой уже несколько дней и наконец понял это. Проблема заключается в том, что Keycloak использует HTTP-заголовок X-Forwarded-Proto при запуске за прокси-сервером, чтобы определить, был ли входящий запрос сделан через HTTPS. Ваш балансировщик нагрузки (в моем случае AWS ELB) должен правильно установить этот заголовок (см. аналогичная проблема ).

При использовании ELB вам необходимо убедиться, что:

  1. Ваш слушатель настроен на HTTPS
  2. Ваш слушатель настроен на TCP, а получающий сервер поддерживает Протокол прокси

В моем случае мои слушатели были настроены на TCP, но серверная часть не была настроена соответствующим образом. Я обнаружил, что NGINX и контроллер входа NGINX Kubernetes поддерживают эту опцию.

0 голосов
/ 26 апреля 2018

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

https://www.keycloak.org/docs/3.3/server_installation/topics/network/https.html

...