Сопоставление имени claim, а не preferred_username claim, с именем пользователя (никнеймом)

Поддержка SSO
1

Знает ли кто-нибудь, можно ли сопоставить утверждение name вместо утверждения preferred_username с именем пользователя (никнеймом), отображаемым при регистрации и в всплывающем окне «Создать учётную запись»?

Вот информация, которую мы получаем от 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"
...
}

По умолчанию в качестве имени пользователя (никнейма) используется preferred_username (в данном примере — «tb»).

Однако мы хотели бы настроить интеграцию таким образом, чтобы вместо этого в качестве имени пользователя (никнейма) использовалось name («Ted Bush»).

Спасибо.

2

Я вижу настройку «Использовать полное имя пользователя при предложении имён пользователей» в разделе настроек пользователей. Но, кажется, она не влияет на OpenID Connect?

Или это работает для всех?

3

Да, у меня это работает при тестировании с сервером Google OAuth2 в качестве провайдера OpenID Connect.

Я думаю, проблема, с которой вы столкнулись, связана с тем, как работает код предложения имён пользователей в Discourse. Keycloak возвращает preferred_username. Если в информации о пользователе, полученной от провайдера идентификации, установлен preferred_username, он имеет приоритет над значением полей name или given_name/family_name.

Для справки, проблема возникает здесь (preferred_username устанавливается как значение username в методе, который вызывается перед этим):

А затем здесь:

Поскольку значение preferred_username является первым аргументом, передаваемым в код предложения имён пользователей, оно будет использовано. Это означает, что настройка use_name_for_username_suggestions не оказывает никакого эффекта в данном случае. Мне кажется, она была предназначена для обработки ситуации, когда провайдер идентификации не возвращает preferred_username.

Я не вижу хорошего обходного пути, если только вы не сможете предотвратить передачу preferred_username от Keycloak в Discourse.

4

@simon, вы правы; я проверил упомянутое вами, используя тестовый экземпляр Keycloak. Когда я настраиваю Keycloak так, чтобы preferred_username не передавался в Discourse, система подстановки имён пользователей в Discourse действительно использует имя и фамилию.

Однако мы не можем настраивать наш промышленный Keycloak таким образом, так как конфигурация клиента используется совместно с несколькими другими клиентами, а не только с Discourse.

Было бы полезно иметь возможность влиять на это поведение в рамках плагина.