Openid-connectプラグインが設定を取得できません

この問題を解決しようと試みていますが、うまくいきません。Discourse と Keycloak のセットアップを、discourse-openid-connect プラグインを使用して認証のために統合しようとしています。Discourse-docker バージョン 3.0.1 を実行しています。現在、OpenID Connect ログインボタンをクリックすると、Discourse に「ID プロバイダーから設定を取得できませんでした。もう一度お試しください。」というメッセージが表示されます。

新しい Discourse セットアップに移行しているのですが、面白いことに、Discourse は古い Keycloak インスタンスを使用して Keycloak ログイン画面に正常にアクセスできますが、新しいインスタンスではできません。これは、以下のことが正しいことを意味します。

  • openid-connect プラグインの設定は間違いなく正しい(古い Discourse からコピーしました)
  • Discourse クライアントの Keycloak 設定は間違いなく正しい(古い Discourse からコピーしました)
  • ネットワークの問題はありません
  • ファイアウォールやトラフィックをブロックしているものはありません

さらに、Discourse インスタンスから Keycloak のディスカバリー ドキュメント URL を正常に curl できることもわかりました。Keycloak のバージョンは古いものと同じで、Keycloak 認証は、Discourse と同じ AWS リージョンおよび AZ にある他のツールでも問題なく機能しています。以下は、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)
「いいね!」 1

プライベート範囲(10.0.0.0/8など)へのアドレスへの到達を許可しないセキュリティパッチがあり、内部ネットワークの探索を防ぎます。

チェックをバイパスするには、管理者 - 設定 - セキュリティ - 許可された内部ホストにホスト名を追加する必要があります。

プラグインが自動的にそれを行ってくれるとよかったのですが。

「いいね!」 2

素晴らしい!では、ここにKeycloakを追加すれば機能するということですね。URLで行うべきか、IPで行うべきでしょうか?

編集:やはり必要ありませんでした。本当にありがとうございました!この問題に多くの時間を費やしましたが、非常に簡単な解決策でした。

「いいね!」 2

@joshml.extra 偶然ですが、私もKeycloak OIDC統合で全く同じ問題を抱えています。@RGJさんが提示された解決策は有望そうです。試してみましたが、私の場合はKubernetes Pod IPのようなIPアドレスでのみ機能しました。

@RGJ - DNSも同様に機能する可能性はありますか?私の場合はNginx Ingress URLで、Nginxコントローラーに内部CA署名証明書があるため、証明書の検証に失敗します。Ingress URLはプライベートIPに解決されます。

このトピックをありがとうございます!!本当に感謝しています :slightly_smiling_face:。エアギャップシナリオの解決策を見つけるのをほとんど諦めていました。

これは、問題がプライベート IP であるようには聞こえません。結局のところ、プライベート IP のためにブロックされた場合、証明書の検証に失敗するほど遠くまで到達することはありませんか?

了解しました。理にかなっています。

説明ありがとうございます。IP / ホスト名で正常に動作しています。

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.