Mappatura della name claim anziché della preferred_username claim all'username (nickname)

SSO
1

Qualcuno sa se è possibile mappare il claim name anziché il claim preferred_username al nome utente (nickname) visualizzato durante la registrazione e mostrato nel pop-up “Crea account”?

Ecco le informazioni che riceviamo da 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"
...
}

Per impostazione predefinita, viene utilizzato preferred_username (in questo esempio, “tb”) come nome utente (nickname).

Tuttavia, vorremmo configurare l’integrazione in modo tale che venga utilizzato name (“Ted Bush”) come nome utente (nickname) invece.

Grazie.

2

Vedo l’impostazione “Usa il nome completo di un utente quando si suggeriscono nomi utente” nella sezione Impostazioni utente. Ma sembra non avere alcun effetto per OpenID Connect?

O funziona per qualcuno?

3

Sì, funziona per me quando lo testo con il server Google OAuth2 come provider OpenID Connect.

Penso che il problema che stai riscontrando sia correlato al modo in cui funziona il codice del suggeritore di nomi utente di Discourse. Keycloak restituisce un preferred_username. Se un preferred_username è impostato nell’userinfo restituito dall’identity provider, ha la precedenza sul valore dei campi name o given_name/family_name.

Come riferimento, il problema si verifica qui (preferred_username è impostato come valore di username in un metodo che viene chiamato prima di questo):

Poi qui:

Poiché il valore di preferred_username è il primo argomento che viene passato al codice del suggeritore di nomi utente, verrà utilizzato. Ciò significa che l’impostazione use_name_for_username_suggestions non ha alcun effetto in questo caso. Penso che fosse inteso per gestire il caso in cui nessun preferred_username venga restituito dall’identity provider.

Non vedo una buona soluzione alternativa, a meno che tu non possa impedire che preferred_username venga passato a Discourse da Keycloak.

1 Mi Piace
4

@simon, hai ragione; ho verificato quanto hai menzionato utilizzando un’istanza di test di Keycloak. Quando configuro Keycloak per omettere preferred_username dal passaggio a Discourse, i nomi e cognomi vengono effettivamente utilizzati dal suggeritore di nomi utente di Discourse.

Tuttavia, non possiamo configurare il nostro Keycloak di produzione in questo modo, poiché la configurazione del client è condivisa con diversi altri client, non solo con Discourse.

Sarebbe utile avere un modo per influenzare questo comportamento all’interno del plugin.

1 Mi Piace