Hallo 
, ich habe dieses SimpleSAMLphp-Authentifizierungsmodul geschrieben, damit Sie Discourse als SSO-Anbieter innerhalb einer SimpleSAMLphp-Installation nutzen können. Das heißt, Sie können Discourse als SSO-Anbieter für beliebige Dienste verwenden, die SAML- oder Shibboleth-Authentifizierung unterstützen, was wirklich praktisch ist.
Lassen Sie mich wissen, was Sie davon halten (falls Sie Interesse haben, den Code zu kommentieren, können Sie GitHub Issues nutzen).
Das ist großartig! Wenn Sie das Modul sichtbarer machen möchten, können Sie in unserer Kategorie #plugin:extras ein Thema dazu erstellen. Diese Kategorie ist ein Verzeichnis aller Erweiterungen und Integrationen für Discourse, die keine Discourse-Plugins sind.
EDIT: Mockup-Bild hinzugefügt
Ich implementiere dieses SSO auf einer bestehenden Website und möchte nur prüfen, wie andere ihre Login-Methode den Nutzern präsentieren.
Nehmen wir zum Beispiel an, meine Website unter www.example.com hat einen Login-Button in der oberen Navigation.
Soll dieser Login-Button die Nutzer sofort zu meiner Discourse-Login-Autorisierungsseite weiterleiten? Oder ist es vorzuziehen, zunächst eine Informationsseite oder ein Modal anzuzeigen, etwa so:
Ich frage mich nur, ob die Nutzer verwirrt sein könnten, wenn sie nicht informiert werden, was als Nächstes passiert? 
Hat jemand Nutzererfahrungen oder Best Practices zu teilen?
Und vielen Dank übrigens an @techAPJ für den sehr detaillierten Eröffnungspost in diesem Thread. Ich konnte dies dank deiner Anleitung erfolgreich von Grund auf in meine ASP.NET-Website integrieren. 
Ist es möglich, einen State-Parameter einzubinden, der unverändert zurückgegeben wird, wie es bei OAuth üblich ist? Das Authentifizierungs-Middleware von ASP.NET Core ist darauf angewiesen, eine Korrelations-ID zu generieren, um CSRF-Angriffe zu verhindern, und ich habe derzeit keine einfache Möglichkeit, diese einzubinden.
Könntest du nicht einen solchen Parameter zur Abfragezeichenfolge deiner Callback-URL hinzufügen, bevor du sie abschließt?
Zum Beispiel:
nonce=NONCE&return_sso_url=https://www.example.com/my/callback_url.aspx?myparam=here
@jessicah Ich habe es heute ausprobiert, und ja, es funktioniert einwandfrei.
' Eine Rückgabe-URL erstellen
Dim strReturnURL As String = "https://www.example.com/authtestRETURNURL.aspx?myownparametershere=surewhynot"
' Eine zufällige Nonce generieren. Temporär speichern, damit Sie sie mit dem zurückgegebenen Nonce-Wert verifizieren können
Dim strNonce As String = Guid.NewGuid().ToString("N")
' Eine neue Nutzlast mit Nonce und Rückgabe-URL erstellen (wo Discourse den Benutzer nach der Verifizierung weiterleitet)
' Die Nutzlast sollte so aussehen: nonce=NONCE&return_sso_url=RETURN_URL
Dim strPayload As String = "nonce=" & strNonce & "&return_sso_url=" & strReturnURL
Auf der Seite, die zurückgerufen wird, finden Sie dies innerhalb Ihrer dekodierten SSO-Abfragezeichenfolge:
&return_sso_url=http%3A%2F%2Fwww.example.com%2FauthtestRETURNURL.aspx%3Fmyownparametershere%3Dsurewhynot&username=RichHoffentlich ist das das, was Sie gemeint haben?
Multi-Site-Ansätze zur Verwendung von discourse-auth-proxy?
Gibt es Beispiele oder Empfehlungen dafür, Discourse als SSO-Anbieter für die Multi-Site-Authentifizierung zu nutzen?
Es scheint, als gäbe es zwei grundlegende Multi-Site-Ansätze:
Ich denke, beide Ansätze könnten funktionieren, aber das Problem bei diesen beiden Methoden besteht darin, dass man sich dennoch bei jeder einzelnen Site anmelden muss.
Es besteht zudem das Risiko, dass etwas in Postgres gespeichert wird, das bei jedem Login von den verschiedenen Sites überschrieben wird. Zum Beispiel: site1.com, site2.com.
(Ich kenne die Details des Discourse-Auth-/PG-Schemas nicht, daher weiß ich das nicht genau.)
Das Ideal wäre eine Möglichkeit, sich einmalig anzumelden und dadurch bei allen Sites in der Multi-Site-Gruppe eingeloggt zu sein. Zum Beispiel: site1.com, site2.com, site3.com.
Anscheinend macht Stackoverflow dies mithilfe einer Kombination aus lokaler Session-Speicherung und Iframes als Hauptmechanismus. technische Beschreibung
Aber ich würde wirklich gerne wissen, ob jemand einen Ansatz für die Multi-Site-Anmeldung mit Discourse als SSO-Anbieter implementiert hat.
Ansatz 1: Mehrere Instanzen von discourse-auth-proxy
Ansatz 2: Modifiziertes discourse-auth-proxy, das return_sso_url in der Nutzlast beeinflusst.
Ansatz 3: #1 oder #2 so implementiert, dass eine einmalige Anmeldung bedeutet, dass man sich beim Wechsel von site1.com zu site2.com nicht erneut anmelden muss.
Ich markiere dich @sam, da du ursprünglich das Go-Programm discourse-auth-proxy geschrieben hast.
Hallo.
Ich stecke fest bei der Frage, wie der Anbieter das Zeichen + in der zurückgegebenen SSO-URL behandelt.
In meinem Fall erstellt mein DiscourseConnect-Consumer eine return_sso_url wie folgt:
http://example.com/foo/bar?wpLoginToken=123+\http%3A%2F%2Fexample.com%2Ffoo%2Fbar%3FwpLoginToken%3D123%2B%5CAnschließend kehrt DiscourseConnect zurück zu:
http://example.com/foo/bar?wpLoginToken=123%20\&sso=foo&sig=barhttp://example.com/foo/bar?wpLoginToken=123+\&sso=foo&sig=barDas Problem ist, dass die Rückkehr-URL von der Funktion urldecode in PHP verarbeitet wird (dies ist der Kernarbeitsablauf der MediaWiki-Authentifizierung), und der Wert von wpLoginToken ändert sich unerwartet von 123+\ zu 123 \.
Es scheint, als hätte ich die Ursache gefunden:
https://www.php.net/manual/en/function.urlencode.php
Nun, der Client und der Server implementieren die Codierung/Dekodierung, folgen jedoch unterschiedlichen Spezifikationen.
Ich fordere Discourse nicht auf, Änderungen vorzunehmen, sondern suche nach Ratschlägen zur Lösung dieses Problems.
Vielen Dank.
Edit:
Ich habe es gelöst, indem ich das Zeichen + zweimal urlcodiert habe.
Danke!
Ich teste das gerade. Ich habe dir zwei PRs auf GitHub geschickt: eine zur Aktualisierung der Dokumentation und eine zur Behebung eines Fehlers, auf den ich gestoßen bin.
In Einstellungen > Anmeldung sind die beiden DiscourseConnect_-Einstellungen für den Anbieter nicht aufeinanderfolgend, sondern zwischen den DiscourseConnect-Einstellungen vermischt:
Da die Einstellungen für den Anbieter und die Nicht-Anbieter-Einstellungen für entgegengesetzte Anwendungsfälle gedacht sind – die Verwendung von Discourse zur Verwaltung von Benutzern für etwas anderes versus die Verwendung von etwas anderem zur Verwaltung von Benutzern für Discourse – lädt die gemischte Darstellung dieser Einstellungen zu Fehlkonfigurationen ein. Es wäre weniger verwirrend, wenn die beiden Anbieter-Einstellungen aufeinanderfolgend und entweder vollständig vor oder vollständig nach den Nicht-Anbieter-Einstellungen angezeigt würden.
@techAPJ Kann dies mit AWS Cognito verwendet werden? Ich möchte eine App in AWS Amplify für meine Discourse-Community erstellen und möchte, dass meine App über Discourse authentifiziert wird.
Entschuldige bitte die sehr verspätete Antwort. Du hast absolut recht – es ist verwirrend, dass sie so vermischt sind. Ich habe das in diesem PR bereinigt:
@mdoggydog Danke für das kürzliche Update der DiscourseSsoConsumer MediaWiki-Erweiterung. Wir haben uns gefragt, was wir tun sollen, da Benutzer von unserem Wiki abgemeldet wurden, ohne sich von Discourse abgemeldet zu haben, und $wgPluggableAuth_EnableAutoLogin war definitiv nicht das, was wir wollten, da es den anonymen Zugriff auf das Wiki verhindert. Die von Ihnen hinzugefügte Einstellung $wgDiscourseSsoConsumer_AutoRelogin ist genau das, was wir brauchten.
Hallo 
!
Ich versuche, das PHP-Beispiel aus dem ursprünglichen Beitrag zu verwenden, aber die Art und Weise, wie sie Dinge speichern, ergibt keinen Sinn. Sie speichern Werte nur in einer SQL-Datenbank mit den Schlüsseln login und nonce. Wenn ich SQL verwenden möchte, um die Nonces zu speichern, wie würde meine SQL-Datenbank genau aussehen?
Einige andere Informationen, die helfen könnten, sind, wofür ich dies verwende – ich hoffe, einen Discourse-Benutzer mit einem Minecraft-Konto zu verknüpfen, indem ich einen SSO-Link generiere, der an ihre UUID gebunden ist. Nach erfolgreichem Login mit Discourse werde ich ihre UUID und ihre Discourse-ID in einer Tabelle speichern.
Bisher konnte ich das PHP-Beispiel zum Laufen bringen, aber ich verstehe nicht ganz, wie ich es für meinen Anwendungsfall anpassen müsste. Idealerweise möchte ich den Link über eine GET-Anfrage generieren und an den Benutzer senden, sodass die UUID bereits mit der Nonce verknüpft ist.
Vielen Dank für diesen Beitrag, ohne ihn wäre ich noch mehr verloren!
Bearbeiten: Wäre es für Nonces besser, Nonces in der Tabelle zu speichern und danach zu suchen? Ich weiß, dass ich die Nonce abgleichen muss, aber es sei denn, ich kann zusätzliche Informationen in der Weiterleitungs-URL übergeben (was mir bisher nicht gelungen ist), bin ich mir nicht sicher, wie ich die Nonce richtig referenzieren kann.
Ich habe eine Anleitung erstellt, die es Administratoren ermöglicht, DiscourseConnect über SimpleSAMLphp in das Standard-SAML-Protokoll zu integrieren.
/session/sso_provider?sso=bm9uY2U9NDA3YTVlNjg1ZTEwMDlh...
Ich bin mir nicht sicher, warum es zu einem 502 Bad Gateway kommt.
Ich habe einen Teil des Werts des sso-Parameters, den Sie angegeben haben, heraus editiert. Solange niemand Ihren geheimen Schlüssel kennt, kann er den Wert nicht entschlüsseln, aber es schien trotzdem sicherer zu sein, nicht den vollständigen Wert anzugeben. Dies hat nichts mit dem 502-Fehler zu tun, den Sie erhalten.
Es scheint ein Datenbankfehler zu sein. Denn ich habe dasselbe Plugin und dieselbe Konfiguration auf einer anderen Discourse-Website ausprobiert, und es funktioniert. Wie kann ich dieses Problem beheben?
Es scheint, dass der Versuch, sich bei discourse-auth-proxy mit Nicht-ASCII-Benutzernamen oder Gruppennamen (in meinem Fall Chinesisch) zu authentifizieren, zu einem Fehler führt, da Cookies diese Zeichen nicht enthalten können. Hier ist meine Korrektur: (Haftungsausschluss: Ich bin mit Golang nicht wirklich vertraut)
diff --git a/main.go b/main.go
index 1b1dc28..18f8c9e 100644
--- a/main.go
+++ b/main.go
@@ -154,7 +154,12 @@ func redirectIfNoCookie(handler http.Handler, r *http.Request, w http.ResponseWr
var username, groups string
if err == nil && cookie != nil {
- username, groups, err = parseCookie(cookie.Value, config.CookieSecret)
+ var value string
+ value, err = url.QueryUnescape(cookie.Value)
+ if err != nil {
+ return
+ }
+ username, groups, err = parseCookie(value, config.CookieSecret)
}
if err == nil {
@@ -224,7 +229,7 @@ func redirectIfNoCookie(handler http.Handler, r *http.Request, w http.ResponseWr
cookieData := strings.Join([]string{username, strings.Join(groups, "|")}, ",")
http.SetCookie(w, &http.Cookie{
Name: cookieName,
- Value: signCookie(cookieData, config.CookieSecret),
+ Value: url.QueryEscape(signCookie(cookieData, config.CookieSecret)),
Expires: expiration,
HttpOnly: true,
Path: "/",
Danke für die Meldung! Würden Sie bitte einen PR gegen das GitHub-Repository erstellen, damit wir diese Änderung in die offizielle Version übernehmen können?