jrack
(Justin Rackliffe)
1
IdP からのクレームを Discourse ユーザーに活用できる SSO プラグインを探しています。
OIDC プラグインでは、userinfo エンドポイントにほぼ固定されます。それは悪くはありませんが、ID ストアの他の情報を使用しようとしており、userinfo の結果は調整できません。OIDC プラグインを id_token_info を使用してユーザーを作成するように強制しようとしましたが、うまくいきませんでした。
oauth プラグインに戻りましたが、表面上は同じ基本的な制限があるように見えます。それは、特定の Иndepoint からのユーザー情報に依存することです。JWT クレームの内容を返すものを探していますが、それは実際には通常のユースケースではないため、あまり期待していません。
oauth basic の「コールバック userinfo パス」を使用してクレームをユーザーにマッピングできると思いましたが、常にレスポンスで null を取得し、挿入に失敗しました。IdP からのトークンをデコードして正しいクレームを確認できます。この場合、JSON のルートに iss、exp などがありますが、ActiveRecord 側に接続できません。
jwt を見ていますが、クレームからユーザーへのマッピングがまったくありません。基本的に、200 を取得すれば問題ないということですが、それも私が探していたものではありませんでした。
omniauth-jwt も見つけましたが、これは私の目標に近いように見えますが、プラグインではなく、積極的にメンテナンスされていないようです。修正できるかもしれませんが、期待していたよりも大きな作業です。
JWT クレームをユーザーにマッピングするための現在メンテナンスされているプラグイン、または既存のプラグインのいずれかで間違っている可能性のある場所を教えていただけますか？
pfaffman
(Jay Pfaffman)
2
jrack
(Justin Rackliffe)
3
うん、もうそこは確認済みです。
私が今日特に鈍いのでなければ、それは固定属性での認証のみをカバーしています。見つけられた範囲では、クレームマッピングを行う方法はありません。もし何かをフォークするとしたら、おそらくそこから始めることになるでしょうが、他に明白なものがないか確認したかったのです。
「いいね！」 1
jrack
(Justin Rackliffe)
4
そして、このトピックにたまたまたどり着いた方のために、もう少し文脈を追加します。
OAuth basic は、定義されたユーザーデータエンドポイントから属性を取得することのみをサポートし、JWT クレームのマッピングはサポートしていないようです。そのため、OIDC プラグインに似ていますが、Discovery Doc によって提供される userinfo の場所の代わりに、任意の JSON エンドポイントをターゲットにして、パスでマッピングできます。認証をヘッダーに含めるための設定を追加すると、Entra ベースの OAuth で使用している https://graph.microsoft.com/v1.0/me のような場所に到達できます。
Entra ID はコアオブジェクトに対していくつかの拡張性を提供しますが、オプションのクレームを追加するほど簡単ではなく、私が確認した限りではグローバルな変更になります。そのため、実際のオプションかどうかはわかりません。さらに成熟度パスを進み、JWT プラグインを使用するのが唯一の道のように思えますが、クレームマッピングサポートを追加するために PR 作業が必要になります。基本的に、既存の oauth2-basic が Discourse フィールドから JSON 属性へのマッピングをカスタマイズできるのと同じように、フィールドから JWT クレームへのマッピングをさらにカスタマイズできるようになる必要があります。
それは私たちにとって一つの道ですが、それをすべて停止させると思われる別の問題に遭遇しました。
oauth2-basic が機能した後、新しいユーザーを求められ、既存の OIDC プラグインの使用からのメールを使用して既存のユーザーがいることがわかります。同じメール属性を共有していても、同じ Discourse ユーザーに対してプロバイダー間を移動できないと思います。全員を最初からやり直させることは現実的な選択肢ではなく、oidc プロバイダーから user_associated_accounts の OAuth プロバイダーレコードの移行をハッキングできるかもしれませんが、問題を引き起こしているような気がします。そのため、JWT がクレームマッピングサポートを持っていたとしても、データベースの操作や「既存ユーザー」ハンドラーを構築して関連付けられたアカウントを変更できるようにしない限り、既存のユーザーは OIDC プロバイダーに固定されているように見えます。
pfaffman
(Jay Pfaffman)
5
それは奇妙ですね。メールアドレスと一致し、同じアカウントに接続されるはずです。OAuthログインはそう機能します。
jrack
(Justin Rackliffe)
6
プロバイダーIDごとに複数のuser_associatedレコードをDiscourseユーザーに許可するか、またはあるプロバイダーから新しいプロバイダーに切り替えるための「リンク」プロンプトを許可することで、連携できることを期待していました。しかし、私のテストではそうではなく、単にメールが使用中であると表示され、新しいユーザーを作成するように促されました。
同じプラグインを使用し続けるのであれば、シームレスに行われると思いますが、この場合はそれぞれ独自のメタデータを持つユニークなプロバイダーIDです。
「いいね！」 1