Ich betreibe eine unabhängige Discourse-Community unter https://physicswithethan.discourse.diy, die zuvor auch institutionelle E-Mail-Adressen und externes SSO (Single Sign-On) zuließ.
Ich möchte nun zu gewöhnlichen lokalen Discourse-Konten mit persönlichen E-Mail-Adressen wechseln und vermeiden, dass neue Registrierungen sich auf institutionelles SSO oder institutionelle E-Mail-Domänen stützen.
Das Problem, das ich sicher handhaben möchte, ist die Kontinuität der Konten und das Risiko der Identitätsmissbrauchs (Impersonation):
Viele bestehende Nutzer haben eine institutionelle E-Mail-Adresse als primäre E-Mail;
Ich möchte, dass neue Nutzer stattdessen persönliche E-Mail-Adressen verwenden;
Ich möchte vermeiden, dass Personen Konten unter dem Namen eines anderen oder unter einer institutionellen E-Mail-Adresse registrieren;
Außerdem möchte ich unsichere oder manuelle Kontozusammenführungen vermeiden, es sei denn, es gibt klare Beweise dafür, dass dieselbe Person die betreffenden Konten/E-Mail-Adressen kontrolliert.
Was ist der empfohlene, native Discourse-Ansatz für dieses Vorhaben?
Beispielsweise wäre das beste Muster:
Lokale Anmeldungen wieder aktivieren;
Den externen SSO-Anbieter deaktivieren;
Die institutionelle Domain zur Liste der blockierten E-Mail-Domains für neue Registrierungen hinzufügen;
Eine Website-Benachrichtigung hinzufügen, die bestehende Nutzer auffordert, ihre primäre E-Mail-Adresse auf eine persönliche Adresse zu aktualisieren;
Manuelle Genehmigung/Überprüfung für verdächtige neue Konten verwenden;
Konten nur zusammenführen, wenn der Nutzer die Kontrolle über beide Konten oder E-Mail-Adressen nachgewiesen hat?
Ich bin besonders daran interessiert, eine Konfiguration zu vermeiden, bei der ein Nutzer E-Mails an die institutionelle Mailbox einer anderen Person auslösen oder ein irreführendes Konto unter dem Namen einer anderen Person erstellen kann.
Gibt es bereits Einstellungen oder Workflows, die für diese Art von Übergang empfohlen werden?
Meinen Sie, dass Sie SSO mit einer bestimmten Institution (z. B. whatever.edu) haben und möchten, dass die Leute diese E-Mail-Adresse nicht mehr nutzen?
Es gibt keine Möglichkeit, in einem beliebigen Szenario E-Mails an ein institutionelles Konto auszulösen (außer einer E-Mail-Bestätigungsanfrage).
Ist es nicht der beste Weg, Leute davon abzuhalten, jemanden zu impersonieren, wenn man verlangt, dass sie ihre institutionelle E-Mail-Adresse verwenden? Es gibt nichts, was jemanden daran hindert, albert.einstein123@gmail.com zu erstellen und so zu tun, als wäre er diese Person.
Ja, genau diese Spannung versuche ich zu bewältigen.
Fachlich stimme ich zu, dass eine institutionelle E-Mail-Adresse eine stärkere Identitätsbestätigung bietet als eine private E-Mail-Adresse. Mein Grund, mich von institutionellen E-Mail-Adressen/SSO (Single Sign-On) zu lösen, ist nicht, dass private E-Mail-Adressen ein besserer Identitätsnachweis sind, sondern dass ich möchte, dass die Gemeinschaft eindeutig unabhängig ist und nicht für den fortlaufenden Zugang auf das Identitätssystem oder die E-Mail-Domäne einer Institution angewiesen ist.
Seit meinem ersten Beitrag habe ich den aktuellen Übergangszustand auf der Website selbst klarer dargestellt:
Die Splash-/Login-Seite gibt nun an, dass Physics with Ethan unabhängig ist und nicht mit einer Universität, Schule oder Abteilung verbunden oder von dieser genehmigt wird;
es wird auch erklärt, dass die Anmeldung derzeit die Verifizierung über Microsoft-Arbeits- oder Schulkonten zur Onboarding-Nutzung nutzt;
bestehende Nutzer können nach der Anmeldung nun eine private E-Mail-Adresse hinzufügen, über Profil → Einstellungen → E-Mails;
ich habe außerdem Hinweise hinzugefügt, die Nutzer auffordern, sich nicht unter dem Namen, der E-Mail-Adresse oder Identität einer anderen Person zu registrieren.
Ich denke also, dass die aktuelle Position eine Übergangslösung ist:
Die Microsoft-Arbeits-/Schul-Verifizierung ist weiterhin nützlich, um das Risiko von Identitätsmissbrauch während des Onboardings zu reduzieren;
aber ich möchte, dass bestehende Nutzer private E-Mail-Adressen hinzufügen;
und ich möchte vermeiden, dass institutionelle E-Mail-Adressen/SSO zur langfristigen Abhängigkeit der Gemeinschaft werden.
Die praktische Discourse-Frage, auf die ich noch eine Antwort suche, ist:
Ist für eine Gemeinschaft, die von institutionellen E-Mail-Adressen/SSO hin zu lokalen Konten und privaten E-Mail-Adressen wechseln möchte, das sicherste Muster, den Übergang manuell/administrativ zu überprüfen, anstatt eine automatische Kontozusammenführung zu versuchen?
Zum Beispiel:
bestehenden Nutzern erlauben, eine private E-Mail-Adresse hinzuzufügen, während sie angemeldet sind;
die Splash-Seite klar über die aktuelle Onboarding-Methode informieren;