Mapping des name claim anstelle des preferred_username claim zum username (Spitzname)

SSO
1

Weiß jemand, ob es möglich ist, den name-Claim anstelle des preferred_username-Claims dem Benutzernamen (Spitznamen) zuzuordnen, der bei der Registrierung angezeigt wird und im Pop-up „Konto erstellen“ erscheint?

Hier sind die Informationen, die wir von Keycloak erhalten:

{
 ..
  "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"
...
}

Standardmäßig wird der preferred_username (in diesem Beispiel „tb“) als Benutzername (Spitzname) verwendet.

Wir möchten die Integration jedoch so konfigurieren, dass stattdessen der name („Ted Bush“) als Benutzername (Spitzname) verwendet wird.

Danke.

2

Ich sehe die Einstellung „Vollständigen Namen eines Benutzers verwenden, wenn Benutzernamen vorgeschlagen werden“ im Abschnitt „Benutzereinstellungen“. Aber sie scheint für OpenID Connect keine Auswirkung zu haben?

Oder funktioniert das bei irgendjemandem?

3

Ja, es funktioniert bei mir, wenn ich es mit dem Google OAuth2-Server als OpenID Connect-Anbieter teste.

Ich glaube, das Problem, auf das Sie stoßen, hängt damit zusammen, wie der Discourse-Benutzernamen-Suggester-Code funktioniert. Keycloak gibt einen preferred_username zurück. Wenn ein preferred_username in den Benutzerinformationen festgelegt ist, die vom Identitätsanbieter zurückgegeben werden, hat dieser Vorrang vor dem Wert der Felder name oder given_name/family_name.

Als Referenz tritt das Problem hier auf (preferred_username wird als Wert von username in einer Methode festgelegt, die davor aufgerufen wird):

Dann hier:

Da der Wert von preferred_username das erste Argument ist, das an den Benutzernamen-Suggester-Code übergeben wird, wird dieser verwendet. Das bedeutet, dass die Einstellung use_name_for_username_suggestions in diesem Fall keine Wirkung hat. Ich glaube, sie war dazu gedacht, den Fall abzufangen, dass kein preferred_username vom Identitätsanbieter zurückgegeben wird.

Ich sehe keinen guten Workaround dafür, es sei denn, Sie können verhindern, dass der preferred_username von Keycloak an Discourse übergeben wird.

1 „Gefällt mir“
4

@simon, Sie haben Recht; ich habe das von Ihnen Erwähnte mit einer Test-Keycloak-Instanz verifiziert. Wenn ich Keycloak so konfiguriere, dass preferred_username nicht an Discourse übergeben wird, werden der Vor- und Nachname tatsächlich vom Discourse-Benutzernamensuggestor verwendet.

Wir können unseren Produktions-Keycloak jedoch nicht auf diese Weise konfigurieren, da die Client-Konfiguration mit mehreren anderen Clients geteilt wird, nicht nur mit Discourse.

Es wäre von Vorteil, wenn es eine Möglichkeit gäbe, dieses Verhalten innerhalb des Plugins zu beeinflussen.

1 „Gefällt mir“