Discourse-ID und 2FA

@JammyDodger, ich habe kürzlich ein Konto für eine kostenlose Instanz registriert:

Dort scheine ich dasselbe Problem zu erleben, das in t/227972 beschrieben wird:

Die meisten Dokumentationen deuten darauf hin, dass dies standardmäßig aktiviert sein sollte:

Ich habe jedoch nicht einmal die Option, es zu aktivieren, und es ist standardmäßig nicht aktiviert:

Ich habe deinen Beitrag hierher verschoben, da es sich um ein anderes Problem handelt als das Contribute > Bug, das du ursprünglich gepostet hast.

Discourse ID verwendet kein OAuth2. Es fungiert im Effekt als SSO-Anbieter, was einen Unterschied darstellt.

Um 2FA zu konfigurieren, musst du dies beim SSO-Anbieter, ID, durchführen. Konkret unter: https://id.discourse.com/my/preferences/security.

@jomaxro, danke. Vielleicht habe ich mich verwirrt, weil ich versucht habe, enforce_second_factor auf „all

Das ist eine gute Frage … und eine, auf die ich keine Antwort habe. Ich habe das Team hinzugezogen, um jemanden zu finden, der sie kennt!

Ich wurde vom Team korrigiert. Discourse ID verwendet tatsächlich OAuth2 im Hintergrund – meine Entschuldigung. Ich dachte, es würde ein anderes Protokoll nutzen.


Zu Ihrer Frage: Wir unterstützen keine Zwei-Faktor-Authentifizierung (2FA) bei externen Anmeldungen. Wie in der von Ihnen gesehenen Meldung angegeben, kann 2FA nicht erzwungen werden, ohne dass lokale Anmeldungen aktiviert sind. Wir verlassen uns darauf, dass der externe Anmeldeanbieter (in diesem Fall Discourse ID, was jedoch für alle externen Anbieter gilt) die 2FA verwaltet, einschließlich der Durchsetzung.

@jomaxro, bedeutet das, dass ich mit dem kostenlosen Test-Plan diese Einstellung nicht ändern kann? Alternativ: Kann ich die Discourse-ID irgendwie trennen?

Möchten Sie sichergehen: Beziehen Sie sich auf eine kostenlose Testversion oder auf den kostenlosen Plan?

@jomaxro, Entschuldigung. Kostenlose Pläne, wie ich glaube:

Frage an uns: Gibt der Identitätsanbieter (IdP) die Information darüber, ob der Benutzer eine Multi-Faktor-Authentifizierung (MFA) durchgeführt hat, an den Diensteanbieter (SP) weiter?

Ich denke an einen analogen Mechanismus zu U2F / FIDO – das Programm kann eine Bestätigung vom Gerät anfordern, wie hoch das erwartete bzw. erforderliche Maß an Benutzerinteraktion für die Zugangsdaten ist.

Wenn Discourse ID – oder ähnlich jeder andere IdP (SAML? OAuth2? OIDC?) – diese Information an den SP weitergibt, wäre dies ein Informationselement, das wir potenziell nutzen könnten.

Wenn nicht, sind wir sozusagen darauf angewiesen, die MFA nach der federierten Anmeldung zu implementieren, um diese Garantie zu erhalten.

Der standardkonforme Weg dafür ist OIDC. Die Discourse-ID wird derzeit ausschließlich auf Basis von OAuth2 implementiert. Um ein MFA-Flag zu unterstützen, müssten wir OIDC auf der Provider-Ebene implementieren und die MFA-Werte für Clients, die dies erfordern, hin und her übermitteln.

Es gibt mehrere Komplikationen:

  • Im Discourse-Kern haben wir die Option, 2FA nur für bestimmte Benutzerarten (Personal oder alle) zu erzwingen; wir benötigen wahrscheinlich eine ähnliche Unterstützung über die ID.
  • Die ID erlaubt Anmeldungen über Google/Apple/Facebook/Github – diese geben jedoch nicht zuverlässig an, ob der Benutzer beim Anmelden 2FA durchgeführt hat. Wir müssten möglicherweise 2FA auf der ID-Ebene implementieren und für einige Benutzer wahrscheinlich eine doppelte 2FA erzwingen, was nicht ideal ist.
  • Ist 2FA auf der Ebene des Identitätsanbieters (das heißt, nicht auf der lokalen Instanz) für alle Verbraucher ausreichend? Generell denke ich ja, aber wir müssten noch etwas mehr recherchieren, bevor wir uns festlegen.