信頼性：OpenID Connectプロバイダーとしてのディスコース

カスタマイズ エキストラ
1

Discourse を認証プロバイダーとして使いたいと思っていた方へ、今なら実現できます！

先週、Discourse をバックエンドとして OpenID Connect/OAuth プロバイダーとして機能する小さなサービスを作成しました。

コードはこちらからご覧いただけます：

私の主なユースケースは Discourse を使って Nextcloud に認証することだったので、あなたのユースケースでは動作しない可能性もあります。

何か期待通りに動作しない場合、または動作させるために「あの」特定の機能が不足している場合は、GitHub リポジトリで issue を作成してください。

「いいね！」 18
Discourse as OpenID Connect provider
Validate User Session on another custom site
3

素晴らしい取り組みですね！Discourse を OAuth プロバイダーとして利用できるようにしたかったのは私自身も同じです。そうすれば、より多くのツールと簡単に統合できるようになります。外部の小さなサービスとして実装するというアプローチも非常に理にかなっています！

「いいね！」 6
4

この提案は非常に魅力的で、いくつかのコミュニティが実際に導入してくれることを願っています！

Discourse 公式として、独自に開発した Discourse Connect 機能に加えて OIDC にも正式に対応してほしいと考えています。それにより、Okta などの外部サービスに依存することなく、Standard および Teams プランの顧客に対して、すぐに導入可能なターンキーソリューションを提供できるようになります。

「いいね！」 7
8

これはすごく素敵ですね！ありがとうございます！

これをDiscourseに組み込んで、独自のOIDCプロバイダーとして機能するようにしてほしいです！

「いいね！」 5
9

素晴らしい、グループ単位でのアクセスを許可できる点が気に入っています。

「いいね！」 1
10

@theSuess 私は Discourse をスタンドアロンで使用していますが、どのように設定すればよいでしょうか？

image
image436×194 15 KB

image
image1155×362 23.7 KB

image
image1144×375 36.1 KB

11

Distrust は個別のサービスであるため、そのようにデプロイする必要があります。README ファイルに記載されている通り、コンテナ内で実行できます。安全に運用するためには、SSL 終端を処理するリバースプロキシも必要になります（将来的にこれを直接実装する可能性があります）。

「いいね！」 2
12

Discourse を SSO プロバイダーとして使用する際に直面している問題について、専門家の意見を伺いたいと思います。

私の目標: Discourse を別のアプリケーション (LibreChat) の認証を処理するように設定しています。Discourse と通信するクライアントとして機能する OIDC ブリッジサービスである distrust を使用して、標準の DiscourseConnect プロバイダー機能を使用しています。

問題: SSO フローは最後のステップまで完璧に機能します。ユーザーは正常に私のアプリから Discourse にリダイレクトされ、Discourse の認証情報で正常にログインできます。しかし、ログイン後、提供された return_sso_url ではなく、私の Discourse フォーラムのホームページ (/) にリダイレクトされます。

行き詰まっている点 (除外したこと): この問題についてしばらくトラブルシューティングを行っており、単純な設定ミスではないことを確認しました。以下の点を明確に除外しました。

  • シークレット: discourse connect provider secrets は正しく設定されています。プロトコルなしのプレーンなドメイン (例: auth.my-site.com) を使用しており、シークレットキーはクライアントサービスのキーと完全に一致しています。
  • SSO モード: enable discourse connect provider がチェックされており、無効な「SSO Client」設定が無効になっていることを確認しました。
  • ユーザーポリシー: must_approve_users が無効になっていること、およびテストユーザーが完全に検証済みのメールを持つ管理者であることを確認しました。
  • プラグイン: すべての非公式のサードパーティ製プラグインを無効にし、コンテナを再構築しましたが、問題は解決しません。

決定的な証拠: 私を困惑させている決定的な証拠が 2 つあります。

  1. HAR ファイル分析: HAR ファイルでネットワークフロー全体をキャプチャしました。ログインのための /session への POST リクエストは成功していることが示されています。サーバーはすぐに 302 Found リダイレクトで応答しますが、Location ヘッダーは一貫して / です。これは、Discourse が SSO リダイレクトを意図的に中止していることを証明しています。
  2. 空の Rails ログ: 次に、ログインを試みている間にコンテナ内の production.log ファイルをテールしました。このプロセス中にログに何も書き込まれません。 これは、Discourse がこれをエラーとして認識しておらず、意図的かつサイレントなアクションであることを示しています。

私の質問: ログインは成功しているものの、リダイレクトが正しくなく、ログにエラーがないことを考えると、Discourse のどの内部ポリシー、事前チェック、または隠し設定が、return_sso_url を無視して代わりにホームページにリダイレクトさせているのでしょうか? 標準的な設定はすべて使い果たしたように感じています。

何かアイデアがあれば、事前に感謝します！