サインアップ時や「アカウント作成」ポップアップに表示されるユーザー名（ニックネーム）に、preferred_username クレームではなく name クレームをマッピングすることは可能でしょうか。\n\n以下は、Keycloak から受け取る情報です。\n\n\n{\n ..\n \"scope\": \"openid email\",\n \"sid\": \"f0f20a2a-19e5-4581-8a45-c1250376f226\",\n \"email_verified\": true,\n \"name\": \"Ted Bush\",\n \"preferred_username\": \"tb\",\n \"given_name\": \"Ted\",\n \"family_name\": \"Bush\",\n \"email\": \"ted.bush@example.com\"\n...\n}\n\n\nデフォルトでは、preferred_username（この例では「tb」）がユーザー名（ニックネーム）として使用されます。\n\nしかし、name（「Ted Bush」）をユーザー名（ニックネーム）として使用するようにインテグレーションを設定したいと考えています。\n\nよろしくお願いします。
「ユーザー名の提案時にユーザーのフルネームを使用する」という設定がユーザー設定セクションにありますが、OpenID Connectには効果がないようです。
それとも、これは誰かに効果があるのでしょうか？
はい、Google OAuth2サーバーをOpenID Connectプロバイダーとしてテストしたところ、私には機能しました。
あなたが直面している問題は、Discourseのユーザー名サジェスターコードの動作方法に関連していると思います。Keycloakは preferred_username を返します。IDプロバイダーから返されるユーザー情報に preferred_username が設定されている場合、それは name または given_name/family_name フィールドの値よりも優先されます。
参考までに、問題はここで発生しています（preferred_username は、これより前に呼び出されるメソッドで username の値として設定されています）。
次に、ここで：
preferred_username の値がユーザー名サジェスターコードに渡される最初の引数であるため、それが使用されます。これは、use_name_for_username_suggestions 設定がこのケースでは効果がないことを意味します。これは、IDプロバイダーから preferred_username が返されないケースを捕捉するために意図されていたのだと思います。
KeycloakからDiscourseに preferred_username が渡されないようにしない限り、これに対する良い回避策は見つかりません。
「いいね！」 1
@simon、ご指摘の通りです。テスト用のKeycloakインスタンスを使用して確認しました。KeycloakをDiscourseにpreferred_usernameを渡さないように設定すると、Discourseのユーザー名サジェスターは実際に名と姓を使用します。
しかし、クライアント設定がDiscourse以外の複数のクライアントと共有されているため、本番環境のKeycloakをこのように設定することはできません。
プラグイン内でこの動作に影響を与える方法があると有益です。
「いいね！」 1