これは素晴らしいです。動作しなかったoauth2プラグインよりもはるかに優れています。しかし、これは(Keycloakで)動作します。
しかし、複数のoidcソースは非常に歓迎される機能となるでしょう。
これは素晴らしいです。動作しなかったoauth2プラグインよりもはるかに優れています。しかし、これは(Keycloakで)動作します。
しかし、複数のoidcソースは非常に歓迎される機能となるでしょう。
それは興味深いアイデアですね。その利点を説明するために、ユースケースについてもう少し詳しく教えていただけますか?また、可能であれば、どのようなログインソースを使用したいですか?
上記の投稿 #2 の質問への回答として、私たちのユースケースと、必要なログインソースについてお伝えします。
私たちは EU の研究イニシアチブのための公開コミュニティフォーラムを運営しており、EU 内のマネージド Discourse ホスティング上で運用しています。
同時に 2 つの OIDC プロバイダーを有効にする必要があります。
https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configuration にあります。どちらのプロバイダーも、もう一方のユーザーをカバーしていません。政策担当者は EU Login でサインインしますが、学術機関の研究 ID は持っていません。研究者は大学アカウントまたはプロキシ経由の ORCID でサインインしますが、EU Login は持っていません。私たちのコミュニティはこれらの両方のグループで構成されているため、プロバイダーを 1 つに限定すると、フォーラムの対象となる人の半分を排除することになります。
両方のプロバイダーは通常の OIDC をサポートしており、それぞれ単独では動作します。問題なのは、discourse-openid-connect が単一の、番号なしの設定ネームスペース openid_connect_client_id を公開している点です。openid_connect_1_client_id や openid_connect_2_client_id のような形式ではありません。サイトごとに設定できる OIDC プロバイダーは 1 つだけです。
複数プロバイダーのサポートを希望します。最も自然な形は、プロバイダーごとの設定ネームスペースであり、番号付きの設定項目または管理者が管理するリストのいずれかです。これにより、各プロバイダーに独自のディスカバリードキュメント、クライアント認証情報、スコープ、ボタンタイトルを割り当てられます。
2021 年の Multiple openid-connect authentication providers という以前の事例があり、そこで必要とされていたのは複数の Keycloak レアルムの対応でした。それは別の形をした同じ制約です。
必要であれば、追加情報やテスト用の実装を提供できます。
試せる方法として、Authentik サービスを設定して、これら 2 つのプロバイダーと「フェデレーション」する という手があります。これにより、チーム内では内部 SSO を、外部ユーザーにはプロキシされた SSO を提供できます。独自の SSO をホストする必要があるため、やや複雑にはなりますが、あなたのリソースの状況によっては、OIDC プラグインのパッチを当てるよりも迅速に対応できるかもしれません。
とはいえ、Discourse の設定の至るところに (Corporate Login Provider) の設定項目が見受けられるため、独自のものを追加できる仕組みがあれば確かに便利だと思います。OIDC プラグインをフォークして名前を変更するという手はどうでしょうか。
アドバイスありがとうございます。EGI Check-inサービスはすでにIdPプロキシとして機能しており、多くのIdPの利用を許可しています。
現在の制約は、EU Loginのポリシーがプロキシの使用を許可していないことです。彼らはサービスとの直接接続を求めています。
その場合、もう一方のサービスがOAuth 2に対応しているなら、Discourse OAuth2 Basic を使って設定し、EU EIDASにはOIDCをそのまま維持できます。以前はSAMLプラグインもありましたが、非推奨になった可能性があります。
ご提案ありがとうございます。確かに、現在 EGI Check-in と Discourse OAuth2 Basic を組み合わせて利用する方法を検討しています。
OIDC プロバイダーを複数サポートする機能は、将来的により多くの組織にメリットをもたらすと考えられ、運用も簡素化されるため、この件をコミュニティの注目に値すると判断しました。
SAML の選択肢はこれまで視野に入れていませんでしたが、検討すべき第三の選択肢となり得るかもしれません。以下のプラグインを見つけました: GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub