Плагин Openid-connect не может получить конфигурацию

Поддержка SSO
1

Я уже довольно давно пытаюсь разобраться в этом вопросе, но не могу решить проблему. Я пытаюсь интегрировать Discourse с настройками Keycloak для аутентификации, используя плагин discourse-openid-connect. Я использую версию discourse-docker 3.0.1. Сейчас при нажатии кнопки входа через OpenID Connect в Discourse появляется сообщение: «Не удалось получить конфигурацию от провайдера идентификации. Пожалуйста, попробуйте снова».

Я мигрирую на новую настройку Discourse, и самое забавное, что Discourse успешно получает доступ к экрану входа в Keycloak с помощью моего СТАРОГО экземпляра Keycloak, но не может сделать этого с новым. Это означает, что следующее должно быть верным:

  • настройки плагина openid-connect точно правильные (скопированы из старого Discourse)
  • настройки Keycloak для клиента Discourse точно правильные (скопированы из старого Discourse)
  • проблем с сетью нет
  • фаервол отключен или ничего не блокирует трафик

Кроме того, я обнаружил, что могу успешно выполнить curl запрос к URL документа обнаружения для Keycloak с экземпляра Discourse. Версия Keycloak такая же, как в старом экземпляре, и аутентификация Keycloak работает корректно для других инструментов, расположенных в том же регионе AWS и зоне доступности, что и Discourse. Ниже приведена ошибка из логов при попытке входа через openid-connect.

Я провел исследования и протестировал множество вариантов, но ничего не сработало. Ошибка о запрещенных IP-адресах кажется довольно общей, и я почти уверен, что фаервол ничего не блокирует, особенно учитывая, что я могу успешно выполнить curl запрос к документу обнаружения. Я могу предположить только, что возможно Discourse пытается получить документ из какого-то кэша или не обращается к правильному URL токена, но я просто не знаю. Любая помощь будет оценена.

Started GET "/session/csrf" for <my_ip> at 2023-02-01 18:02:24 +0000
Processing by SessionController#csrf as JSON
Completed 200 OK in 2ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 406)
Started POST "/auth/oidc" for 10.158.133.85 at 2023-02-01 18:02:24 +0000
(oidc) Setup endpoint detected, running now.
OIDC Log: Fetching discovery document from https://<keycloak_URL>.com/auth/realms/<my_realm>/.well-known/openid-configuration
OIDC Log: Fetching discovery document raised error Faraday::ConnectionFailed FinalDestination: all resolved IPs were disallowed
OIDC Log: Discovery document is

---

(oidc) Request phase initiated.
(oidc) Authentication failure! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError, Discovery document is missing
Started GET "/auth/failure?message=openid_connect_discovery_error&strategy=oidc" for <my_ip> at 2023-02-01 18:02:24 +0000
Processing by Users::OmniauthCallbacksController#failure as HTML
  Parameters: {"message"=>"openid_connect_discovery_error", "strategy"=>"oidc"}
  Rendered users/omniauth_callbacks/failure.html.erb within layouts/no_ember (Duration: 0.1ms | Allocations: 17)
  Rendered layout layouts/no_ember.html.erb (Duration: 17.3ms | Allocations: 5113)
Completed 200 OK in 24ms (Views: 19.7ms | ActiveRecord: 0.0ms | Allocations: 6610)
2

Существует патч безопасности, который запрещает обращение к адресам в частных диапазонах (10.0.0.0/8 и т. д.), чтобы предотвратить исследование внутренней сети.

Чтобы обойти эту проверку, вам нужно добавить имя хоста в раздел «Администрирование» → «Настройки» → «Безопасность» → «Разрешённые внутренние хосты».

Было бы неплохо, если бы плагин делал это за вас.

4

Отлично! Значит, если я добавлю сюда свой Keycloak, всё должно заработать? Буду ли я использовать для этого URL или IP-адрес?

РЕДАКТИРОВАНИЕ: Забыл, это сработало. Большое спасибо! Я потратил так много времени на это, а решение оказалось таким простым.

5

@joshml.extra, какое совпадение — я столкнулся с точно такой же проблемой при интеграции Keycloak через OIDC, и решение, предложенное @RGJ, выглядит многообещающе. Я попробовал его, но оно сработало только для IP-адреса, в моём случае — для IP-адреса пода в Kubernetes.

@RGJ — возможно ли, чтобы DNS работал аналогичным образом? В моём случае это URL Nginx Ingress, и я вижу ошибку проверки сертификата, так как на контроллере Nginx используются сертификаты, подписанные внутренним УЦ. URL Ingress разрешается в частный IP-адрес.

Спасибо за эту тему!! Очень признателен :slightly_smiling_face:. Я уже почти отказался от поиска решения для нашей изолированной (air-gapped) среды.

6

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

7

Понял! Имеет смысл.

Спасибо за объяснение. У меня всё работает отлично с IP-адресом / именем хоста.