Mapeo del 'name claim' en lugar del 'preferred_username claim' al nombre de usuario (apodo)

SSO
1

¿Alguien sabe si es posible mapear el claim name en lugar del claim preferred_username al nombre de usuario (apodo) que se muestra durante el registro y en la ventana emergente ‘Crear cuenta’?

Aquí está la información que recibimos 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"
...
}

Por defecto, se utiliza preferred_username (en este ejemplo, “tb”) como nombre de usuario (apodo).

Sin embargo, nos gustaría configurar la integración de tal manera que se utilice name (“Ted Bush”) como nombre de usuario (apodo) en su lugar.

Gracias.

2

Veo la configuración “Usar el nombre completo de un usuario al sugerir nombres de usuario” en la sección de configuración de Usuarios. Pero parece no tener ningún efecto para OpenID Connect.

¿O esto funciona para alguien?

3

Sí, funciona para mí al probarlo con el servidor OAuth2 de Google como proveedor de OpenID Connect.

Creo que el problema que estás experimentando está relacionado con cómo funciona el código del sugeridor de nombres de usuario de Discourse. Keycloak devuelve un preferred_username. Si se establece un preferred_username en la información del usuario que se devuelve del proveedor de identidad, tiene prioridad sobre el valor de los campos name o given_name/family_name.

Como referencia, el problema ocurre aquí (el preferred_username se establece como el valor de username en un método que se llama antes de esto):

Luego aquí:

Dado que el valor de preferred_username es el primer argumento que se pasa al código del sugeridor de nombres de usuario, se utilizará. Eso significa que la configuración use_name_for_username_suggestions no tiene ningún efecto en este caso. Creo que estaba destinada a capturar el caso en que no se devuelve ningún preferred_username del proveedor de identidad.

No veo una buena solución alternativa para esto, a menos que puedas evitar que el preferred_username se pase a Discourse desde Keycloak.

1 me gusta
4

@simon, tienes razón; he verificado lo que mencionaste usando una instancia de prueba de Keycloak. Cuando configuro Keycloak para omitir preferred_username al pasarlo a Discourse, los nombres y apellidos son utilizados por el sugeridor de nombres de usuario de Discourse.

Sin embargo, no podemos configurar nuestro Keycloak de producción de esta manera, ya que la configuración del cliente se comparte con varios otros clientes, no solo con Discourse.

Sería beneficioso tener una forma de influir en este comportamiento dentro del plugin.

1 me gusta