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

プラグイン エキストラ
1

If you ever wanted to use Discourse as your authentication provider - now you can!

Over the last week I’ve written a small service which can be used to act as an OpenID connect/OAuth provider with discourse as a backend.

You can check out the code here:

Note that my primary use case was to authenticate to Nextcloud using Discourse, so it might not be working for your use case.

If something is not working as expected, or it is missing that certain feature to make it work for you, feel free to create an issue in the GitHub repository.

「いいね！」 18
3

Awesome initiative! I always wanted Discourse to be usable as an OAuth provider, so it can easily be integrated with more tools. Making it an external small service makes a lot of sense too!

「いいね！」 6
4

I like the sound of this and hope some communities decide to try it out!

I’d love to see OIDC supported by Discourse officially in addition to our bespoke Discourse Connect functionality, so we can offer a turnkey solution to our customers on standard and teams without having to rely on okta or the like.

「いいね！」 7
8

This is super cool! Thanks for doing this!

I would really like to see this built in to Discourse so that it could be its own OIDC provider!

「いいね！」 5
9

Awesome, I love that it allows access by group.

「いいね！」 1
10

@theSuess I am using discourse as stand alone then how Can I configure it?
image

image
image1155×362 23.7 KB

image
image1144×375 36.1 KB

11

Distrust is a separate service, so you need to deploy it as such. You can run it in a container as described in the README file. Note that for secure operation, you will also need a reverse proxy handling SSL Termination (I might implement this directly sometime in the future).

「いいね！」 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 を無視して代わりにホームページにリダイレクトさせているのでしょうか? 標準的な設定はすべて使い果たしたように感じています。

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