username(닉네임)에 preferred_username 대신 name 클레임을 매핑하는 것

회원가입 시 표시되고 ‘계정 생성’ 팝업에 나타나는 사용자 이름(닉네임)에 preferred_username 대신 name 클레임을 매핑할 수 있는지 아는 분이 있을까요?

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”)가 사용자 이름(닉네임)으로 사용됩니다.

하지만 preferred_username 대신 name(“Ted Bush”)을 사용자 이름(닉네임)으로 사용하도록 통합을 구성하고 싶습니다.

감사합니다.

사용자 설정 섹션에서 "사용자 이름 제안 시 사용자의 전체 이름을 사용하십시오."라는 설정을 볼 수 있습니다. 하지만 OpenID Connect에는 효과가 없는 것 같습니다.

아니면 이 설정이 실제로 작동하는 사람이 있는 건가요?

저는 Google OAuth2 서버를 OpenID Connect 제공자로 사용하여 테스트했을 때 잘 작동했습니다.

질문자님이 겪고 계신 문제는 Discourse의 사용자명 제안(username suggester) 코드의 작동 방식과 관련이 있을 것 같습니다. Keycloak은 preferred_username을 반환합니다. 인증 제공자(Identity Provider)에서 반환된 userinfo에 preferred_username이 설정되어 있다면, 이는 name 필드 또는 given_name/family_name 필드의 값보다 우선순위가 높습니다.

참고로, 문제가 발생하는 곳은 다음과 같습니다(preferred_username은 이 메서드가 호출되기 전에 username의 값으로 설정됩니다):

그리고 다음 부분입니다:

preferred_username의 값이 사용자명 제안 코드에 전달되는 첫 번째 인자이므로, 이 값이 사용하게 됩니다. 즉, 이 경우 use_name_for_username_suggestions 설정은 효과를 발휘하지 못합니다. 제 생각에는 이 설정은 인증 제공자로부터 preferred_username이 반환되지 않는 경우를 처리하기 위해 의도된 것으로 보입니다.

Keycloak에서 preferred_username이 Discourse로 전달되는 것을 막을 수 있는 방법이 없다면, 이 문제에 대한 좋은 우회 방법을 찾지 못했습니다.

@simon님, 말씀하신 내용이 맞습니다. 테스트용 Keycloak 인스턴스를 통해 확인해 보았습니다. Keycloak 설정에서 preferred_username을 Discourse로 전달하지 않도록 하면, Discourse의 사용자 이름 제안기에서 실제로 이름과 성이 사용되더군요.

하지만 프로덕션 Keycloak는 이 방식으로 설정할 수 없습니다. 클라이언트 설정이 Discourse 외에도 여러 다른 클라이언트와 공유되고 있기 때문입니다.

플러그인 내에서 이 동작을 제어할 수 있는 방법이 있으면 좋겠습니다.