Discourse OpenID Connect (OIDC)

Hallo @balazsorban44, danke für die Erinnerung daran. Ich habe die PR zum ersten Mal überprüft. Wenn der Autor keine Zeit hat, an diesen Dingen zu arbeiten, dann ist es wahrscheinlich etwas, das wir übernehmen können. Ich stimme zu, dass PKCE-Unterstützung gut wäre.

Es ist jedoch erwähnenswert: Ich glaube nicht, dass Discourse anfällig für die „Authorization Code Interception“-Angriffe ist, vor denen PKCE schützt. Die Authentifizierung von Discourse erfolgt immer im Browser über https und verwendet keine benutzerdefinierten URL-Schemata auf Betriebssystemebene, die von anderen Apps abgefangen werden können.

Aber natürlich schadet es nicht, die zusätzliche Sicherheitsebene hinzuzufügen :+1:

3 „Gefällt mir“

Nicht unbedingt besorgt über die Sicherheit.

Ich habe das Feedback hier berücksichtigt und die Historie des ursprünglichen Mitwirkenden zur Anerkennung beibehalten: feat: PKCE support by balazsorban44 · Pull Request #86 · discourse/discourse-openid-connect · GitHub

Ich bin gerne bereit, die Arbeit daran abzuschließen :slight_smile:

2 „Gefällt mir“

Haben Sie eine Lösung dafür gefunden?

Leider nein.

@swt2c Ich habe es in das Plugin gehackt, indem ich Folgendes hinzugefügt habe

  params << ["client_id", "<my-client-id>"]
  params << ["logout_uri", post_logout_redirect] if post_logout_redirect

nach der Zeile params << ["post_logout_redirect_uri", post_logout_redirect] if post_logout_redirect in plugin.rb.

Es wäre großartig, offizielle Unterstützung dafür zu bekommen!

@balazsorban44 Danke, dass du dich darum kümmerst! Ich habe gerade den PR zusammengeführt, sodass wir jetzt optionalen PKCE-Support im Plugin haben :tada:

4 „Gefällt mir“

Hallo Chris,
wie hast du Authentik mit diesem Plugin integriert? Jede Einsicht wäre hilfreich. Wir kämpfen seit ein paar Wochen damit, es richtig zum Laufen zu bringen.

Hmm, ich kann mich an nichts Besonderes erinnern. Was genau ist Ihr Problem? Möchten Sie vielleicht Screenshots Ihrer Konfiguration teilen (per PN)?

1 „Gefällt mir“

Danke für die Antwort, Chris. Sicher. Ich werde mich später in dieser Woche mit Ihnen in Verbindung setzen, wenn mein Entwicklungsteam, das an Authentik gearbeitet hat, anwesend ist. Die Hauptprobleme betreffen den Flow und den Outpost.

1 „Gefällt mir“

Ich habe ein interessantes Problem: Bevor ich es öffentlich bereitstelle, möchte ich testen, ob alles funktioniert. Daher wird mein OIDC-Anbieter lokal gehostet (privates Subnetz) und ist nicht aus dem Internet erreichbar.
Leider schlägt dies fehl, da Discourse keine Verbindung zu privaten IPs zulässt.
oidc.example.org wird zu einer privaten IP aufgelöst.

OIDC Log: Fetching discovery document from https://oidc.example.org/application/o/discourse/.well-known/openid-configuration
OIDC Log: Fetching discovery document raised error Faraday::ConnectionFailed FinalDestination: all resolved IPs were disallowed
OIDC Log: Discovery document is

---

(oidc) Request phase initiated.
(oidc) Authentication failure! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError, Discovery document is missing

Ich denke, da openid_connect_discovery_document nur vom Administrator geändert werden kann, sollte es vertrauenswürdig sein und auch private IPs zulassen.

Es gibt eine Website-Einstellung namens „allowed_internal_hosts“. Wenn Sie den internen Hostnamen zu dieser Liste hinzufügen, werden Anfragen an diesen vom SSRF Detector zugelassen.

Bei Shared-Hosting-Diensten (wie dem offiziellen Hosting von discourse.org) werden Administratoren nicht vertraut, Anfragen innerhalb der Hosting-Umgebung zu stellen. Deshalb gibt es diesen Schutz standardmäßig.

Entschuldigung, aber ich bin mir nicht sicher, ob ich der Anweisung folgen kann, das Plugin zu installieren. Ich betreibe Discourse in meiner lokalen Docker-Umgebung und kann eigentlich keine app.yml finden, um die Konfiguration hinzuzufügen.
Es könnte eine dumme Frage sein, aber gibt es eine Anleitung, um es in einer lokalen Entwicklungsumgebung zu installieren?

Versuchen Sie für eine Docker-Entwicklungsumgebung, unter /var/discourse/containers/app.yml nachzusehen?
Für Nicht-Docker-Entwicklungsinstallationen sehen Sie hier nach:

1 „Gefällt mir“

Das Problem ist, dass ich keinen Ordner „Container“ finden kann.

Wenn Sie dieser Anleitung gefolgt sind, können Sie vielleicht diesem Beitrag folgen, um Plugins zu installieren?

Hallo.\nIch habe dieses Plugin hinzugefügt und es funktioniert gut. Das Problem, das ich sehe, ist, dass unsere Discourse-App Aliase hat, sodass ich mich mit 2 URLs anmelden kann. Beide wurden in Azure mit den richtigen Callback-URLs konfiguriert. Mir ist aufgefallen, dass der Aufruf an https://discourse.company.com/auth/oidc die Location-URL mit der Alias-URL zurückgibt, wie z. B. https://login-blah-bla/authorize?client_id=&redirect_uri=https%3A%2F%[2Fdiscourse.us.company.com](http://2fdiscourse.us.company.com/)%2Fauth%2Foidc%2Fcallback.\nSollte es nicht die ursprüngliche URL respektieren?\n\nEs gibt openid_connect_error_redirects, aber das ist meiner Meinung nach für den Fall von Fehlern. Irgendeine Idee, wie ich die Umleitung zur Autorität (auch bekannt als discourse.company.com) ändern kann.

Bei einer manuellen Bundler-Installation erhalte ich folgendes:

Nachinstallationsmeldung von oauth2:

Sie haben oauth2 Version 1.4.11 installiert, die am Ende ihres Lebenszyklus ist.
Weitere Unterstützung für die Serie 1.4.x wird nicht erwartet.

und Empfehlungen, auf oauth2 Version 2 zu aktualisieren. Ich würde mich viel wohler fühlen ohne solche Nachrichten. Gibt es Pläne für ein Upgrade?

Außerdem erhalte ich:
Sie haben oauth Version 1.1.0 installiert, herzlichen Glückwunsch!

Nicht-kommerzielle Unterstützung für die Serie 1.x endet bis April 2025. Bitte planen Sie ein Upgrade auf die nächste Version vor diesem Datum.
Das einzige breaking Change wird die Unterstützung für Ruby 2.7 und andere Versionen sein, die bis dahin ebenfalls das Ende ihres Lebenszyklus erreicht haben.

Aber ich vermute, das ist nicht “Sie”?

Hallo,
die Option “Neue Registrierungen zulassen” ist für die Funktion des Plugins unbedingt erforderlich. Dadurch wird das Konto bei der ersten Anmeldung bei Discourse automatisch erstellt und eine Schaltfläche “Registrieren” angezeigt. Wäre es aber möglich, die Deaktivierung zu ermöglichen: d.h. dem Benutzer, der sich über openidconnect anmeldet, nicht die Möglichkeit zu geben, seine Parameter zu ändern und sein Konto direkt zu erstellen. Dadurch könnten die “Registrieren”-Schaltflächen, die in diesem Kontext nicht benötigt werden, aus der Anzeige entfernt werden.
Mit freundlichen Grüßen

Hast du es herausgefunden? Ich hänge bei der gleichen Meldung fest.

Hey, konntest du das einrichten? Ich weiß nicht, warum ich hier völlig feststecke, von den Hunderten von Apps, die ich mit OpenID oder Auth verwaltet habe, macht mir diese die meisten Probleme.