Ich versuche, bei einem Umstrukturierungsprojekt, an dem ich arbeite, meine Optionen klarer zu verstehen. Ich habe in den Foren nach weiteren Einblicken gesucht und dabei zwar eine ähnliche Anfrage gefunden, doch das Szenario des Fragestellers unterscheidet sich etwas von unserem. Daher eröffne ich hier ein neues Thema.
Wir haben derzeit eine WordPress-Seite unter domain.com, die als SSO-Client für die Discourse-Instanz unter community.domain.com konfiguriert ist. Die WP-Seite wird jedoch in ein Multisite-Netzwerk umorganisiert, z. B. sub1.newdomain.com, sub2.newdomain.com usw., mit einer separaten Discourse-Instanz für jede Seite, z. B. forum.sub1.newdomain.com (oder idealerweise sub1.newdomain.com/forum, falls wir die Subordner-Konfiguration hinbekommen).
Wir möchten, dass unsere Benutzer über alle Communities hinweg eine einzige Identität haben. Wir wissen, wie man Benutzer, die sich bei einem WP-Subsite registrieren, im gesamten Netzwerk synchronisieren. Mir ist bewusst, dass eine Discourse-Instanz als SSO-Server für eine andere fungieren kann, aber ich konnte keine Bestätigung finden, wie dies konfiguriert wird oder ob dies für mehrere Discourse-Clients funktioniert.
Also zu meinen Fragen:
Ist es im beschriebenen Szenario möglich, eine Discourse-Instanz unter z. B. auth.newdomain.com so zu konfigurieren, dass sie sowohl als SSO-Server für das WPMS-Netzwerk als auch für alle Discourse-Instanzen fungiert, die mit den Subsites verknüpft sind?
Hey – das ist bei mir aufgetaucht, da du auf mein ursprüngliches Thema verlinkt hast. Ich lasse @simon gerne seine Gedanken dazu äußern, aber eine Option, die für dich funktionieren könnte oder auch nicht (und die deutlich einfacher wäre), besteht darin, eine einzelne Discourse-Instanz einzurichten und Gruppen zu verwenden, um die Foren zu trennen. Gruppeninformationen können im SSO-Payload übermittelt werden.
Allerdings sollte die Einrichtung mehrerer Foren, bei denen eines als SSO-Anbieter fungiert, recht unkompliziert sein (obwohl ich das bisher noch nicht ausprobiert habe). Meines Erachtens wären die Schritte:
Das WP Discourse-Plugin installieren und als SSO-Client konfigurieren (in den Netzwerkeinstellungen).
Das Discourse-Forum einrichten, das als SSO-Anbieter fungieren soll (geheime Schlüssel in WP und Discourse hinzufügen usw.).
Von dort aus werden weitere hinzugefügte Foren als SSO-Clients konfiguriert (und da WP Discourse auf Netzwerkebene eingerichtet ist, musst du beim Hinzufügen neuer Sites keine Konfigurationen ändern).
Vielen Dank für deine Vorschläge, @jakeols. Ich weiß, dass Gruppen die am häufigsten vorgeschlagene Alternative sind, aber sie passen nicht für unseren speziellen Anwendungsfall.
Ich hoffe, @simon kann uns einige Einblicke geben, was hier möglich ist und was nicht.
Du kannst Discourse als SSO-Anbieter in einem Multisite-Netzwerk verwenden. Dies ist nur aktiviert, wenn du eine einzelne Discourse-Website als SSO-Anbieter für alle Websites im Netzwerk einrichtest. Der Grund dafür ist, dass in einem Multisite-Netzwerk alle Benutzer in einer einzigen Datenbanktabelle gespeichert sind. Wenn mehrere Discourse-Websites als SSO-Anbieter für mehrere Websites in einem Netzwerk fungieren dürfen, gibt es keine einfache Möglichkeit, sicherzustellen, dass die in WordPress gespeicherten Discourse-Benutzer-IDs eindeutig sind.
Wenn das WP Discourse-Plugin in einem Multisite-Netzwerk installiert ist, wird dem Menü der Netzwerkverwaltung ein Discourse-Tab hinzugefügt. Um Discourse als SSO-Anbieter für alle Websites im Netzwerk zu konfigurieren, gehe zur Seite der Netzwerkverwaltung und wähle im Menü Discourse aus. Wähle die Option „Multisite-Konfiguration aktivieren“ aus und gib dann die Verbindungseinstellungen ein. Scrolle dann auf der Seite nach unten zum Abschnitt SSO-Einstellungen. Wähle die Option „SSO-Client aktivieren“ aus. Gib deinen SSO-Geheimen Schlüssel ein und speichere die Einstellungsseite.
Eine Sache, die du beachten solltest, ist, dass die Aktivierung der SSO-Client-Funktionalität in einem Multisite-Netzwerk potenziell jedem Benutzer auf deinem Discourse-Forum Zugriff auf jede Website in deinem Netzwerk gewährt.
Im Wesentlichen: Wenn du versuchst, etwas anderes als das oben Beschriebene mit der Nutzung von Discourse als SSO-Anbieter für ein WordPress-Multisite-Netzwerk zu erreichen, bist du auf dich allein gestellt. Es wäre technisch möglich, mehreren Discourse-Websites zu erlauben, als SSO-Anbieter für einzelne Websites in einem WordPress-Netzwerk zu fungieren, aber die dafür erforderliche Konfiguration wäre übermäßig komplex. Ich glaube nicht, dass dies jemals zum WordPress-Plugin hinzugefügt wird.
Vielen Dank für deine Antwort. Der von dir zitierte Beitrag war genau das, worauf ich mich in meinem ursprünglichen Beitrag bezogen habe. Auf WordPress-Seite haben wir eigentlich keine Probleme – wir wissen, wie man auf Netzwerkebene eine Verbindung herstellt und dann die Benutzer über alle Subsites synchronisiert. Was ich eher verstehen möchte, ist, wie man einen Discourse so konfigurieren kann, dass er als SSO-Server für einen anderen Discourse dient. Ich wollte klären, ob dies möglich ist, während der „auth“-Discourse gleichzeitig auch der SSO-Server für WordPress ist.
Ich konnte keine Dokumentation zur Discourse-Discourse-Konfiguration finden. Wenn du mir zeigen könntest, wo ich weitere Informationen finde, oder mir einfach die notwendigen Schritte skizzieren könntest, wäre ich außerordentlich dankbar.
Ich verstehe, worauf du hinauswillst, aber Discourse ist nicht dafür gedacht, ausschließlich für Authentifizierungszwecke verwendet zu werden. Ich würde dir empfehlen, dir etwas Zeit zu nehmen, um einen dedizierten Authentifizierungsdienst zu prüfen, den du mit deinen verschiedenen Discourse- und WordPress-Instanzen verbindest. Eine gewisse Investition in Recherche jetzt kann sich später auszahlen.
Mein wichtigster Rat an dich ist jedoch: Was du vorschlägst, ist komplex. Unabhängig für welchen Weg du dich entscheidest, musst du eine Staging-Umgebung einrichten, die deiner geplanten Produktionsumgebung entspricht, um verschiedene Konfigurationen zu testen, bevor du sie live schaltest. Eine solche Einrichtung kann von zahlreichen verschiedenen Variablen beeinflusst werden, und es ist schwierig, hierzu allgemein gültige Ratschläge zu geben.
Ich weiß, dass die Einrichtung einer völlig separaten Staging-Umgebung für ein vernetztes Server-System mühsam erscheinen mag, aber der Aufwand dafür ist weitaus geringer als der Versuch, unvorhergesehene Probleme zu lösen, die nach dem Start einer solchen Einrichtung auftreten.
Ja, mir ist bewusst, dass Discourse kein reiner Authentifizierungsdienst ist. Wir prüfen derzeit drei mögliche Optionen:
Discourse als unseren Identity Provider nutzen
WordPress als unseren Identity Provider nutzen
Einen externen (SaaS oder selbst gehosteten) Identity Provider nutzen
Jede dieser Optionen hat unterschiedliche Auswirkungen auf Kosten, Komplexität und Benutzererfahrung, die wir bewerten möchten – daher meine Fragen hier.
Nein, du hast zu 100 % recht, es ist komplex, und wir würden niemals ohne vorheriges Testen in einer Staging-Umgebung deployen. Vielen Dank für die Erklärung, sehr geschätzt!
