Hat jemand bereits SSO für eine Townnews-Website eingerichtet?
Mir ist keine Website bekannt, die Townnews oder BLOX CMS mit Discourse SSO nutzt. Weißt du, ob es möglich ist, Code zu einer Website hinzuzufügen, die diesen Dienst verwendet? Falls der Discourse SSO-Code auf der Website hinzugefügt werden kann, könnte es möglich sein, ihn als SSO-Anbieter für Discourse zu verwenden.
Entschuldigung, ich bin neu, aber ich meinte die Verwendung von TownNews als SSO-Quelle. Welchen Code müsste ich zur Website hinzufügen?
Das bedeutet, dass Townnews der SSO-Anbieter für Ihre Discourse-Seite wäre. Um die SSO-Implementierung von Discourse zu nutzen, müssen Sie in der Lage sein, Code in den Dienst einzufügen, der als SSO-Anbieter fungiert. Dieser Code muss in den Anmeldeprozess des Dienstes integriert werden. Details zum erforderlichen Code finden Sie hier: Offizielles Single-Sign-On für Discourse (sso).
Für ein funktionierendes Code-Beispiel werfen Sie einen Blick darauf, wie unser WordPress-Plugin SSO implementiert: wp-discourse/lib/sso-provider at main · discourse/wp-discourse · GitHub.
Es könnte auch möglich sein, Benutzer über Townnews mit OAuth2 in Discourse anzumelden. Dies wäre der Fall, wenn Townnews als OAuth2-Anbieter fungieren kann. Details zur Einrichtung von OAuth2-Anmeldungen mit Discourse finden Sie hier: OAuth2-Basisunterstützung. Bevor Sie zu viel Zeit damit verbringen, wäre es gut zu bestätigen, ob Townnews als OAuth2-Anbieter fungieren kann. Dies sollte anhand ihrer Dokumentation herauszufinden sein.
Ich versuche, mich mit meinem Site-Anbieter abzustimmen, aber ich wollte dies mit Ihnen teilen, um zu sehen, ob Sie Informationen daraus verwenden können, um mir zu helfen. Ich danke Ihnen für die Zeit.
Umleitung zum Provider-Endpunkt
Jede BLOX-CMS-Site verfügt über einen Endpunkt für die föderierte Authentifizierung unter derselben reservierten URL:
https://www.example.com/tncms/auth/federated/
Der Consumer-Site leitet die Authentifizierung ein, indem er den Browser des Benutzers zu dieser URL umleitet. Der Endpunkt erfordert einen Parameter return, der auf die URL des Endpunkts der Consumer-Site gesetzt werden muss.
Ein Beispiel für eine URL:
https://www.example.com/tncms/auth/federated/?return=http://vendor.com/login/
Der Endpunkt akzeptiert zudem weitere Parameter:
-
source : Dieser Parameter und sein Wert werden an die Login-URL der Site übergeben, falls eine Authentifizierung des Benutzers erforderlich ist. Templates können auf diesen Wert reagieren, um die Benutzeroberfläche des Login-Formulars anzupassen. Falls nicht angegeben, wird standardmäßig der Wert „federated“ verwendet.
-
reauth : Auf einen wahrheitsfähigen Wert setzen, um die Login-Seite unabhängig vom aktuellen Anmeldestatus des Benutzers anzuzeigen.
Umleitung zum Consumer-Endpunkt
Die URL des Endpunkts der Consumer-Site wird dem Provider im Parameter return übergeben, wenn der Benutzer zunächst zum Endpunkt des Providers umgeleitet wird. Nach erfolgreicher Authentifizierung beim Provider wird der Benutzer zusammen mit einem Parameter code zu dieser URL umgeleitet. Der Wert von code muss in einem sofortigen Folgewebservice-Call, wie unten beschrieben, gegen die Kontodaten des Benutzers eingetauscht werden.
Die Endpunkt-URL der Consumer-Site kann eigene Abfrageparameter enthalten. Der Parameter code wird dabei mit diesen zusammengeführt, ohne die anderen Werte zu überschreiben.
Je nach Implementierung der Templates auf der Provider-Site kann es vorkommen, dass der Benutzer den Consumer-Endpunkt ohne einen Wert für code erreicht. In diesem Fall ist der Benutzer so zu behandeln, als hätte er den Authentifizierungsprozess abgebrochen.
Ein Beispiel für eine Antwort bei erfolgreicher Anmeldung (basierend auf dem vorherigen Beispiel):
http://vendor.com/login/?code={code}
Dabei ist {code} eine eindeutige Kennung für die Verwendung im nachfolgenden Webservice.
Folgewebservice-Call
Wenn der Benutzer mit einem gültigen Code am Endpunkt der Consumer-Site ankommt, sollte die Consumer-Site sofort einen Webservice-Call an den Provider ausführen, um den Code gegen die Kontoinformationen des Benutzers einzutauschen.
Die Consumer-Site ruft die Aktion get des Benutzersmoduls auf und übergibt dabei den vom Provider erhaltenen Parameter code:
https://www.example.com/tncms/webservice/v1/user/get/?code={code}
Die Antwort ist ein Datenobjekt des Benutzerkontos, wie in der Webservice-Dokumentation beschrieben. Bei einem ungültigen Code wird eine Null-Antwort zurückgegeben.
Ein Code ist nur einmal verwendbar. Nach der Verwendung zum Abrufen eines Benutzerkontos wird er sofort ungültig gemacht, und zukünftige Anfragen mit diesem Code führen zu Null-Antworten.
Das sieht vielversprechend aus: https://help.bloxcms.com/knowledge-base/applications/settings/users/authentication_provider/article_fa0ce6ec-9824-11e4-b296-23bd78ef308a.html:
Die Option Authentifizierungsanbieter ermöglicht es Ihrer Website, als OpenID-Authentifizierungsanbieter zu fungieren. Das bedeutet, dass Nutzer Ihrer Website ihre Zugangsdaten von Ihrer Website verwenden können, um sich bei anderen Websites anzumelden, die dies zulassen. Andere BLOX CMS-Websites könnten als Client-Websites fungieren und diesen Austausch von Anmeldeinformationen ermöglichen.
Es sollte möglich sein, eine BLOX CMS-Website so zu konfigurieren, dass sie als OpenID-Authentifizierungsanbieter für Discourse dient. In diesem Fall könnten Benutzer über Ihre TownNews-Website in Ihr Discourse-Forum einloggen. Zur Einrichtung müssen Sie das Plugin Discourse OpenID Connect (OIDC) auf Ihrer Discourse-Website installieren. Die Konfiguration könnte einige Versuche und Irrtümer erfordern. Lassen Sie es uns wissen, falls Sie feststecken, und wir versuchen, Ihnen zu helfen.