Mapeando a reivindicação name em vez da reivindicação preferred_username para o nome de usuário (apelido)

SSO
1

Alguém sabe se é possível mapear a claim name em vez da claim preferred_username para o nome de usuário (apelido) exibido durante o cadastro e na janela pop-up “Criar Conta”?

Aqui estão as informações que recebemos do 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 padrão, o preferred_username (neste exemplo, “tb”) é usado como nome de usuário (apelido).

No entanto, gostaríamos de configurar a integração de forma que o name (“Ted Bush”) seja usado como nome de usuário (apelido) em vez disso.

Obrigado.

2

Vejo a configuração “Usar o nome completo de um usuário ao sugerir nomes de usuário” na seção de Configurações do Usuário. Mas parece não ter efeito para OpenID Connect?

Ou isso funciona para alguém?

3

Sim, funciona para mim ao testá-lo com o servidor Google OAuth2 como provedor OpenID Connect.

Eu acho que o problema que você está enfrentando está relacionado a como o código de sugestão de nome de usuário do Discourse funciona. O Keycloak está retornando um preferred_username. Se um preferred_username for definido no userinfo retornado pelo provedor de identidade, ele terá precedência sobre o valor dos campos name ou given_name/family_name.

Para referência, o problema está acontecendo aqui (preferred_username é definido como o valor de username em um método que é chamado antes disso):

Então, aqui:

Como o valor de preferred_username é o primeiro argumento que é passado para o código de sugestão de nome de usuário, ele será usado. Isso significa que a configuração use_name_for_username_suggestions não está tendo nenhum efeito para este caso. Acho que foi projetado para capturar o caso de nenhum preferred_username ser retornado do provedor de identidade.

Não estou vendo uma boa solução alternativa para isso, a menos que você possa impedir que o preferred_username seja passado para o Discourse a partir do Keycloak.

1 curtida
4

@simon, você está correto; Verifiquei o que você mencionou usando uma instância de teste do Keycloak. Quando configuro o Keycloak para omitir preferred_username de ser passado para o Discourse, os nomes e sobrenomes são de fato usados pelo sugestor de nome de usuário do Discourse.

No entanto, não podemos configurar nosso Keycloak de produção dessa maneira, pois a configuração do cliente é compartilhada com vários outros clientes, não apenas com o Discourse.

Seria benéfico ter uma maneira de influenciar esse comportamento dentro do plugin.

1 curtida