このシナリオでは、私のRelying Party（RP）はユーザに関する情報を取得するだけでなく、ユーザをRPの内部ユーザにマッピングする必要もあります。このため、Identity Provider（IdP）の既存のユーザーをRPのユーザー/グループにマップしたいと考えています。私はOpenID Connect（IdPとRPは信頼関係を持っています;どちらも私によって管理されています）でこれを達成するにはどうしたらいいですか？OpenID Connectでのユーザマッピング依頼者
この問題を解決するその他の方法を教えてください。
ここでは2つのアプローチがあります。 1つはOpenID Connectの視点からのものです。もう1つはユーザーディレクトリの処理です。
イドトークン請求項
OpenIDの接続仕様は、IDトークン（トークンID定義と前記説明にlink）の特許請求の範囲を規定します。そしてそれは私たち自身の主張を持つ自由を私たちに与えます。たとえば、RPがsubのエンドユーザーを識別してマッピングするという主張に依存できない場合、standard claims以外のカスタム請求を導入することができます。
IDトークンには、他のクレームが含まれる可能性があります。使用されていないクレームは無視されなければなりません。
例えば、RPのユーザIDを与えるidトークンにはrp_identifierというクレームを定義することができます。
IDPには何らかの設定が必要です。また、IDPストレージに必要なIDを格納する必要があります。
ディレクトリ同期
ユーザーディレクトリが設定されているかわかりません。しかし、外部IDPを使用している場合は、内部および外部のユーザーディレクトリを同期させたい場合があります。私はこのドメインの専門家ではありませんが、参考のためにthisの記事でAzureのアクティブなディレクトリ同期について説明しています。
ユーザー同期はOpenID Connectの対象外ですが、OpenID Connectに移行する人の多くは、内部ユーザーをIDP提供のユーザーにマップする必要があります。
Idトークンのすべての既存サブ（サブジェクト識別子）を読みたいと思います：while私はRPのためにIDP（またはその主張）に特別なものを追加したくないという可能性を見ています。私のRPはサブクレームに頼ることができましたが、私のRPは何を期待するべきかを知る必要があります。 ディレクトリ同期：内部IDPです。目標は、RPのIDPからディレクトリを読み出すことです（RPはすでにLDAPと同様のことをしています）。 – Dunken
@Dunken私が提案したのは、あなたのRPから他の識別子にsubsをマップする方法でした。私が知る限り、OIDC doeはあなたのRPに何を期待するかを知らせるための他の方法を提供していません。 IDトークンの検証とエンドユーザーの特定は、RPまでです。 RPのユーザーレジストリの変更について考えないでください。 –
Btw、LDAPを使用しているので、これを見ているかもしれません - https://lsc-project.org/doku.phpこれはLDAPユーザの同期に関するものです –
エンドトークンを使用してエンドユーザーを認証していますか？また、それが当てはまる場合、あなたが現在持っている問題は、内部トークンとサブトークンのサブパラメータの不一致ですか？ –
ディレクトリ同期についても考えましたか？ –
ディレクトリ（IDPからRP）を同期する方法がわかりません、それは問題です... – Dunken