Mapping the name claim rather than the preferred_username claim to the username (nickname)

sso
1

Does anyone know if it’s possible to map the name claim rather than the preferred_username claim to the username (nickname) displayed during signup and shown in the ‘Create Account’ pop-up?

Here is the information we receive from 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"
...
}

By default, the preferred_username (in this example, “tb”) is used as the username (nickname).

However, we would like to configure the integration in such a way that the name (“Ted Bush”) is used as the username (nickname) instead.

Thanks.

2

I see the “Use a user’s full name when suggesting usernames.” setting in the Users setting section. But it seems to have no effect for OpenID Connect?

Or does this work for anybody?

3

Yes, it works for me when testing it with the Google OAuth2 server as the OpenID Connect provider.

I think the issue you are running into is related to how the Discourse username suggester code works. Keycloak is returning a preferred_username. If a preferred_username is set in the userinfo that’s returned from the identity provider, it takes precedence over the value of either the name or given_name/family_name fields.

For reference, the problem is happening here (preferred_username is set as the value of username in a method that gets called before this):

Then here:

Since the value of preferred_username is the first argument that gets passed to the username suggester code, it will get used. That means that the use_name_for_username_suggestions setting isn’t having any effect for this case. I think it was intended to catch the case of no preferred_username being passed back from the identity provider.

I’m not seeing a good workaround for this, unless you can prevent the preferred_username from being passed to Discourse from Keycloak.

1 Like
4

@simon, you are correct; I have verified what you mentioned using a test Keycloak instance. When I configure Keycloak to omit preferred_username from being passed to Discourse, the first and last names are indeed used by the Discourse username suggester.

However, we cannot configure our production Keycloak in this manner, as the client configuration is shared with several other clients, not just Discourse.

It would be beneficial to have a way to influence this behaviour within the plugin.

1 Like