Mapping von JWT-Claims zu einem Discourse-Benutzer über ein Login-Plugin

SSO
,
1

Ich versuche schon seit einiger Zeit, ein SSO-Plugin zu finden, mit dem ich die Claims meines IdP für meine Discourse-Benutzer nutzen kann.

Beim OIDC-Plugin ist man ziemlich auf den Userinfo-Endpunkt beschränkt. Das ist nicht schlecht, aber ich wollte andere Informationen aus unserem Identitätsspeicher verwenden, und das Ergebnis von Userinfo kann nicht angepasst werden. Ich habe versucht, das OIDC-Plugin zu zwingen, die id_token_info zu verwenden, um den Benutzer zu erstellen, aber ohne Erfolg.

Ich bin zum oauth-Plugin zurückgekehrt, aber oberflächlich betrachtet scheint es die gleiche grundlegende Einschränkung zu haben, nämlich dass es auf Benutzerinformationen von einem bestimmten Endpunkt angewiesen ist. Ich versuche herauszufinden, ob ich eines finden kann, das den Inhalt der JWT-Claims zurückgibt, aber das ist kein normaler Anwendungsfall, daher erwarte ich nicht viel.

Ich dachte ursprünglich, dass die “callback userinfo paths” im oauth basic verwendet werden könnten, um die Claims dem Benutzer zuzuordnen, aber ich erhalte immer nur Nullwerte in der Antwort und die Einfügung schlägt fehl. Ich kann den Token vom IdP dekodieren und die richtigen Claims sehen, in diesem Fall auf der Root-Ebene des JSON, wie iss, exp usw., aber ich kann sie nicht mit der ActiveRecord-Seite verbinden.

Ich schaue mir jwt an, aber es scheint keine Zuordnung von Claims zu Benutzern zu geben. Grundsätzlich, wenn man ein 200 erhält, ist alles gut, was auch nicht das ist, wonach ich gesucht habe.

Ich habe auch omniauth-jwt](GitHub - discourse/discourse-omniauth-jwt: An OmniAuth strategy that uses JSON Web Token for Single Sign-On) gefunden, das meinem Ziel näher zu kommen scheint, obwohl es kein Plugin zu sein scheint und nicht aktiv gepflegt wird. Etwas, das ich vielleicht beheben könnte, aber ein größerer Aufwand, als ich gehofft hatte.

Kann mir jemand eine Richtung für ein aktuell gepflegtes Plugin zur Zuordnung von JWT-Claims zu einem Benutzer geben oder wo ich bei einem der bestehenden Plugins falsch liege?

2

Ich habe keine Ahnung, aber ich würde GitHub - discourse/all-the-plugins nehmen und nach OmniAuth greppen. Das gibt dir eine Menge Plugins, die Das gibt dir GitHub - discourse/discourse-jwt: Discourse Auth support for JSON Web Tokens (JWT), was vielleicht das ist, wonach du suchst.

3

Ja, das habe ich bereits durchgesehen.

Wenn ich heute nicht besonders stumpf bin, deckt es nur die Authentifizierung mit festen Attributen ab. Keine Möglichkeit, eine Anspruchszuordnung zu finden, die ich finden konnte. Wenn ich etwas forken würde, wäre das wahrscheinlich dort, wo ich anfangen würde, aber ich wollte sichergehen, dass ich nichts Offensichtliches übersehe.

1 „Gefällt mir“
4

Und um den Kontext für Leute, die auf dieses Thema stoßen, noch etwas zu erweitern.

Das OAuth-Basic scheint nur das Abrufen von Attributen von einem definierten Benutzerdatenendpunkt zu unterstützen und unterstützt keine Zuordnung von JWT-Claims. Es ähnelt also dem OIDC-Plugin, aber anstelle des vom Discovery-Dokument bereitgestellten Userinfo-Speicherorts können Sie jeden JSON-Endpunkt anvisieren und dann per Pfad zuordnen. Wenn Sie die Einstellungen für die Einbeziehung der Authentifizierung in den Header hinzufügen, können Sie Orte wie https://graph.microsoft.com/v1.0/me erreichen, die wir für Entra-basiertes OAuth verwenden.

Nun bietet Entra ID einige Erweiterungsmöglichkeiten für Kernobjekte, aber es ist nicht so einfach, wie einen optionalen Claim anzuhängen, und es wäre eine globale Änderung, soweit ich das sehe. Daher bin ich mir nicht sicher, ob dies eine wirkliche Option für uns ist. Wenn man noch weiter zurückgeht und den Reifegrad betrachtet und einfach das JWT-Plugin verwendet, scheint dies der einzige Weg zu sein, aber es würde einige PR-Arbeit erfordern, um die Zuordnung von Claims zu unterstützen. Im Grunde müsste es auf die gleiche Weise, wie das bestehende oauth2-basic die Zuordnung des Discourse-Feldes zu einem JSON-Attribut ermöglicht, mehr Anpassungsmöglichkeiten für die Zuordnung von Feldern zu JWT-Claims erlauben.

Das ist nun ein Weg für uns, aber ich bin auf ein anderes Problem gestoßen, das meiner Meinung nach alles stoppt.

Nachdem oauth2-basic funktioniert, fordert es einen neuen Benutzer an und stellt fest, dass bereits ein Benutzer mit der E-Mail-Adresse des bestehenden OIDC-Plugins vorhanden ist. Obwohl sie das gleiche E-Mail-Attribut haben, kann es meiner Meinung nach nicht zwischen Anbietern für denselben Discourse-Benutzer wechseln. Alle neu anfangen zu lassen, ist keine wirkliche Option, und obwohl ich wahrscheinlich einen Migrationsdatensatz für einen OAuth-Anbieter in user_associated_accounts von einem OIDC-Anbieter hacken könnte, fühlt es sich an, als würde ich nur Ärger suchen. Selbst wenn JWT die Unterstützung für die Zuordnung von Claims hätte, sind alle bestehenden Benutzer ohne einige Datenbank-Spielereien oder die Erstellung eines “bestehenden Benutzers”-Handlers, der die Änderung zugeordneter Konten erlaubt, an den OIDC-Anbieter gebunden, und es scheint, als ob man feststeckt.

5

Das ist seltsam. Es sollte die E-Mail-Adresse abgleichen und sich mit demselben Konto verbinden, würde man meinen. Die OAuth-Logins funktionieren auf diese Weise.

6

Ich hatte gehofft, dass sie entweder durch die Zulassung von mehr als einem user_associated-Datensatz pro Discourse-Benutzer (pro provider_id) oder durch eine “Verknüpfungsaufforderung” zum Wechsel von einem Anbieter zu einem neuen Anbieter eine Verbindung herstellen würden. In meinen Tests war dies jedoch nicht der Fall, und es wird lediglich die E-Mail als bereits verwendet vermerkt und zur Erstellung eines neuen Benutzers aufgefordert.

Wenn ich beim selben Plugin geblieben wäre, bin ich sicher, dass es nahtlos gewesen wäre, aber in diesem Fall handelt es sich um eindeutige Anbieter-IDs mit jeweils eigenen Metadaten.

1 „Gefällt mir“