Das ist großartig, viel besser als das OAuth2-Plugin, das nicht funktionierte. Aber dieses hier funktioniert (mit Keycloak).
Allerdings wären mehrere OIDC-Quellen eine sehr willkommene Funktion.
Das ist eine interessante Idee. Können Sie uns mehr über Ihren Anwendungsfall erzählen, um die Vorteile zu erläutern, und wenn möglich, welche Anmeldequellen Sie verwenden möchten?
Antwort auf die Frage in Beitrag #2 oben: Unser Anwendungsfall und welche Login-Quellen wir benötigen.
Wir betreiben ein öffentliches Community-Forum für eine EU-Forschungsinitiative auf gehostetem Discourse innerhalb der EU.
Wir müssen zwei OIDC-Provider gleichzeitig aktivieren:
- EU Login, der Identitätsanbieter der Europäischen Kommission. Er wird von Kommissionsbediensteten, politischen Stakeholdern und Teilnehmern an EU-geförderten Projekten verwendet. Standard-OIDC, mit dem Discovery-Dokument unter
https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configuration. - EGI Check-in, ein föderierter akademischer Identitäts-Proxy, der institutionelle Konten und ORCID abdeckt. Er wird in den europäischen Forschungsinfrastrukturen eingesetzt. Ebenfalls Standard-OIDC.
Keiner der beiden deckt die Nutzer des anderen ab. Eine Politikoffizierin meldet sich mit EU Login an und hat keine institutionelle Forschungsidentität. Eine Forscherin meldet sich über unseren Proxy mit einem Universitätskonto oder mit ORCID an und hat kein EU Login. Unsere Community besteht aus beiden Gruppen, sodass die Wahl eines einzelnen Anbieters bedeutet, die Hälfte der Personen abzuweisen, für die das Forum gedacht ist.
Beide Provider nutzen gewöhnliches OIDC, und jeder funktioniert für sich allein. Was uns daran hindert, ist, dass discourse-openid-connect einen einzelnen, nicht nummerierten Einstellungsnamespace bereitstellt: openid_connect_client_id, statt openid_connect_1_client_id und openid_connect_2_client_id. Pro Site kann nur ein OIDC-Provider konfiguriert werden.
Wir würden Unterstützung für mehrere Provider wünschen. Die natürlichste Form wäre ein Einstellungsnamespace pro Provider, entweder nummerierte Einstellungen oder eine von der Verwaltung verwaltete Liste, bei der jeder Provider sein eigenes Discovery-Dokument, seine eigenen Client-Zugangsdaten, seinen eigenen Scope und seinen eigenen Button-Titel hat.
Es gibt frühere Vorarbeiten in Mehrere openid-connect-Authentifizierungsprovider aus dem Jahr 2021, wo der Bedarf mehrere Keycloak-Reiche betraf. Das ist dieselbe Einschränkung in anderer Form.
Wir können bei Bedarf weitere Informationen bereitstellen oder Implementierungen testen, falls das helfen kann.
1 „Gefällt mir“
Eine Option wäre, einen Authentik-Service einzurichten und mit diesen beiden Providern zu „föderieren“. So könntet ihr intern SSO für euer Team nutzen und für externe Benutzer ein proxiedes SSO anbieten. Das wäre etwas aufwendiger, da ihr euer eigenes SSO selbst hosten müsst, aber je nach euren Kapazitäten vielleicht schneller, als das OIDC-Plugin patchen zu müssen.
Dennoch sehe ich in den Discourse-Einstellungen überall (Corporate Login Provider)-Optionen, daher wäre es tatsächlich schön, wenn wir unsere eigenen hinzufügen könnten. Vielleicht den OIDC-Plugin forken und die Namen anpassen?
4 „Gefällt mir“
Danke für den Hinweis. Der EGI Check-in-Dienst ist bereits ein IdP-Proxy, der die Nutzung vieler IdPs ermöglicht.
Die aktuelle Einschränkung besteht darin, dass die EU-Login-Richtlinie die Verwendung eines Proxys nicht zulässt. Sie verlangen eine direkte Verbindung zum Dienst.
1 „Gefällt mir“
In dem Fall, wenn die andere Seite OAuth2 unterstützen kann, kannst du es mit Discourse OAuth2 Basic konfigurieren, sodass du OIDC für die EU EIDAS beibehalten kannst. Es gab auch ein SAML-Plugin, das aber möglicherweise veraltet ist.
2 „Gefällt mir“
Danke für den Vorschlag. Tatsächlich prüfen wir derzeit die Nutzung von Discourse OAuth2 Basic mit EGI Check-in.
Ich wollte diesen Fall der Community vorstellen, da die Möglichkeit, mehrere OIDC-Anbieter zu unterstützen, in Zukunft wahrscheinlich vielen Organisationen zugutekommen und die Dinge vereinfachen wird.
Die SAML-Option war uns nicht bekannt. Sie könnte eine dritte Option sein, die man in Betracht ziehen sollte. Ich habe das Plugin gefunden: GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub
2 „Gefällt mir“