Associer la claim 'name' plutôt que la claim 'preferred_username' au nom d'utilisateur (surnom)

SSO
1

Quelqu’un sait-il s’il est possible de mapper la revendication name plutôt que la revendication preferred_username au nom d’utilisateur (surnom) affiché lors de l’inscription et dans la fenêtre contextuelle « Créer un compte » ?

Voici les informations que nous recevons de Keycloak :

{
 ..
  "scope": "openid email",
  "sid": "f0f20a2a-19e5-4581-8a45-c1250376f226",
  "email_verified": true,
  "name": "Ted Bush",
  "preferred_username": "tb",
  "given_name": "Ted",
  "family_name": "Bush",
  "email": "ted.bush@example.com"
...
}

Par défaut, le preferred_username (dans cet exemple, « tb ») est utilisé comme nom d’utilisateur (surnom).

Cependant, nous aimerions configurer l’intégration de telle sorte que le name (« Ted Bush ») soit utilisé comme nom d’utilisateur (surnom) à la place.

Merci.

2

Je vois le paramètre « Utiliser le nom complet d’un utilisateur lors de la suggestion de noms d’utilisateur » dans la section des paramètres des utilisateurs. Mais il semble n’avoir aucun effet pour OpenID Connect ?

Ou cela fonctionne-t-il pour quelqu’un ?

3

Oui, cela fonctionne pour moi lorsque je le teste avec le serveur Google OAuth2 comme fournisseur OpenID Connect.

Je pense que le problème que vous rencontrez est lié au fonctionnement du code suggérant les noms d’utilisateur de Discourse. Keycloak renvoie un preferred_username. Si un preferred_username est défini dans les informations utilisateur (userinfo) renvoyées par le fournisseur d’identité, il a la priorité sur la valeur des champs name ou given_name/family_name.

À titre de référence, le problème se produit ici (preferred_username est défini comme la valeur de username dans une méthode qui est appelée avant cela) :

Puis ici :

Étant donné que la valeur de preferred_username est le premier argument passé au code suggérant les noms d’utilisateur, elle sera utilisée. Cela signifie que le paramètre use_name_for_username_suggestions n’a aucun effet dans ce cas. Je pense qu’il était destiné à gérer le cas où aucun preferred_username n’est renvoyé par le fournisseur d’identité.

Je ne vois pas de bonne solution de contournement, à moins que vous ne puissiez empêcher le preferred_username d’être transmis à Discourse depuis Keycloak.

1 « J'aime »
4

@simon, vous avez raison ; j’ai vérifié ce que vous avez mentionné en utilisant une instance de test de Keycloak. Lorsque je configure Keycloak pour omettre preferred_username lors du passage à Discourse, les prénoms et noms de famille sont effectivement utilisés par le suggéreur de noms d’utilisateur de Discourse.

Cependant, nous ne pouvons pas configurer notre Keycloak de production de cette manière, car la configuration du client est partagée avec plusieurs autres clients, pas seulement Discourse.

Il serait bénéfique d’avoir un moyen d’influencer ce comportement au sein du plugin.

1 « J'aime »