So schränken Sie die Benutzerregistrierung auf einem selbstgehosteten Matrix-Server ein

Auf einem selbst gehosteten Matrix-Server kann „Registrierung einschränken“ von der Verhinderung aller öffentlichen Anmeldungen bis hin zur Beschränkung auf Personen mit Einladungscode alles bedeuten. Für Synapse ist die einfachste Lösung, die öffentliche Registrierung zu deaktivieren. Wenn Sie dennoch neue Mitglieder aufnehmen möchten, benötigen Sie Registrierungstoken und stellen Sie jedem Mitglied ein zeitlich begrenztes Token zur Verfügung. Diese Einstellungen betreffen die Erstellung neuer lokaler Konten; bestehende Benutzer werden dadurch nicht entfernt und die Matrix-Föderation nicht deaktiviert.

Wählen Sie das Steuerelement, das zu Ihrem Server passt.

Die folgenden Beispiele beziehen sich auf Synapse. Dendrite, Conduit und andere Homeserver-Implementierungen verwenden unterschiedliche Konfigurations- und Verwaltungsschnittstellen. Lesen Sie die Dokumentation Ihres Servers, bevor Sie Synapse-Einstellungen anwenden.

Option 1: Öffentliche Registrierung deaktivieren

Bei einem privaten Heimserver, einer kleinen Organisation oder einem Server, auf dem ein Administrator jedes Konto einrichtet, deaktivieren Sie die Clientregistrierung in der aktiven Synapse-Konfiguration:

enable_registration: false

Synapse dokumentiert diese Einstellung als standardmäßig deaktiviert. Bearbeiten Sie die Konfigurationsdatei, die Ihr Dienst oder Container lädt, überprüfen Sie die YAML-Datei und starten Sie Synapse anschließend wie gewohnt neu. Bei einer Docker-Bereitstellung kann die Konfiguration von einem Hostpfad eingebunden werden. Daher ändert das Bearbeiten einer gleichnamigen Datei im Container möglicherweise nicht die beim Start verwendete Datei.

Wenn die Registrierung deaktiviert ist, können Benutzer keine neuen Konten über den regulären Client-Registrierungsprozess erstellen. Administratoren können weiterhin Konten über die unterstützten administrativen Methoden erstellen. Synapse warnt ausdrücklich davor, dass diese Einstellung registration_shared_secretdie Kontoerstellung mit diesem Geheimnis ermöglicht, selbst wenn enable_registrationes deaktiviert ist. Behandeln Sie es als besonders sensible Zugangsdaten: Halten Sie es von Repositories, Chats und öffentlichen Umgebungsdateien fern; beschränken Sie den Zugriff; und bewahren Sie es nur auf, wenn Ihr administrativer Workflow es erfordert. Jeder, der das Geheimnis kennt, kann Konten erstellen, einschließlich Administratorkonten.

Wenn Sie OIDC, CAS oder eine andere SSO-Integration verwenden, überprüfen Sie auch die automatischen Registrierungseinstellungen des jeweiligen Anbieters. Synapse dokumentiert die Registrierungseinstellungen auf Anbieterebene, da andernfalls bei der ersten erfolgreichen SSO-Anmeldung automatisch ein Benutzer angelegt werden könnte. Überprüfen Sie bei OIDC oidc_providers[].enable_registrationsowohl die allgemeinen Registrierungseinstellungen als auch die automatischen Registrierungseinstellungen.

Option 2: Registrierung nur mit Tokens zulassen

Verwenden Sie Registrierungstoken, wenn Mitglieder zwar eigene Konten erstellen können sollen, Anmeldungen aber von einem Administrator genehmigt oder verteilt werden müssen. Legen Sie in der Synapse-Konfiguration beide Werte fest:

enable_registration: true
registration_requires_token: true

Beides ist erforderlich: Die Token-Einstellung benötigt ein Token bei der Registrierung, und die Registrierung selbst muss ebenfalls aktiviert sein. Übernehmen Sie die Änderung und starten Sie Synapse neu. Bestehende Konten und zuvor erstellte Token werden durch diese Einstellungsänderung nicht gelöscht.

Erstelle ein Token mit begrenzter Nutzungsdauer.

Synapse bietet eine Admin-API für Registrierungstoken. Anfragen erfordern ein Administratorzugriffstoken. Beispielsweise erzeugt diese Anfrage ein Token, mit dem eine Registrierung durchgeführt werden kann:

curl -sS -X POST "$SYNAPSE_URL/_synapse/admin/v1/registration_tokens/new" \
  -H "Authorization: Bearer $ADMIN_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"uses_allowed": 1}'

Ersetzen Sie die Umgebungsvariablen durch die Basis-URL Ihres Homeservers und ein Administratorzugriffstoken. Halten Sie das Administratorzugriffstoken geheim und vermeiden Sie es, Befehle mit echten Zugangsdaten in freigegebene Protokolle oder Support-Anfragen einzufügen. Die API akzeptiert auch eine Gültigkeitsdauer in Millisekunden seit der Unix-Epoche. Verwenden Sie ein Einmaltoken für eine einzelne Einladung und legen Sie eine Gültigkeitsdauer fest, die Ihr Workflow zuverlässig berechnen und verwalten kann. Ein Token ohne Limitangaben kann unbegrenzt oft verwendet werden und hat keine Gültigkeitsdauer. Überprüfen Sie daher die zurückgegebenen Felder, bevor Sie es verteilen.

Um Tokens zu überprüfen, kann ein Administrator die entsprechende Funktion aufrufen GET /_synapse/admin/v1/registration_tokens. Die Antwort enthält Informationen zu zulässigen Nutzungen, ausstehenden und abgeschlossenen Registrierungen sowie zum Ablaufdatum. Sollte ein Token kompromittiert worden sein, setzen Sie die zulässigen Nutzungen auf null oder löschen Sie das Token über die dokumentierte Admin-API. Ein Token dient als Anmeldeinformation und ist keine Einladung zu einem Matrix-Raum; es fügt das neue Konto nicht automatisch einem Raum hinzu.

Wichtiger Hinweis zur Kompatibilität: Die Admin-API für Registrierungstoken von Synapse ist deaktiviert, wenn die Integration des Matrix Authentication Service (MAS) aktiviert ist. Verwenden Sie in diesem Fall stattdessen die für Ihre Bereitstellung dokumentierte MAS-Admin-API oder MAS-CLI. Gehen Sie nicht davon aus, dass ein Synapse-Token-Befehl unverändert mit MAS funktioniert.

Option 3: Hinzufügen von Prüfungen zur öffentlichen Registrierung

Wenn Sie jedem die Kontoeröffnung ermöglichen möchten, ist die Verwendung von Tokens möglicherweise zu restriktiv. Die Synapse-Konfiguration dokumentiert auch CAPTCHA- und Drittanbieter-Identifikationsanforderungen als mögliche Prüfverfahren. CAPTCHA ist von einem korrekt konfigurierten Anbieter abhängig und kann zusätzliche Kosten für Barrierefreiheit und Datenschutz verursachen. Die Angabe einer E-Mail-Adresse oder Telefonnummer kann zusätzlichen Aufwand für Einrichtung und Verifizierung bedeuten; sie ist nicht mit der Genehmigung jedes einzelnen Kontos gleichzusetzen. Prüfen Sie, welche Verifizierungsdienste Ihre Version und Ihr Client-Workflow tatsächlich unterstützen, bevor Sie eine Drittanbieter-Identifikationsanforderung als zusätzliche Hürde festlegen.

Die Ratenbegrenzung ist in Verbindung mit diesen Kontrollmechanismen sinnvoll, da sie wiederholte Anfragen reduziert. Sie legt jedoch nicht fest, wer sich registrieren darf. Überwachen Sie Registrierungsversuche und Serverprotokolle und passen Sie die Grenzwerte an Ihren Datenverkehr und Ihre Bereitstellung an. Vermeiden Sie es, alte Konfigurationsabschnitte zu kopieren, ohne Ihre installierte Synapse-Version zu überprüfen: Die Optionen für Registrierung und Identitätsdienst haben sich im Laufe der Zeit geändert.

Was die Schließung der Registrierungsstelle ändert – und was nicht – ändert sich

• Es steuert die Erstellung neuer lokaler Benutzerkonten. Durch Deaktivieren der Registrierung wird der normale Ablauf zur Kontoerstellung auf Ihrem Homeserver blockiert.
• Es werden keine Konten gelöscht. Bestehende Benutzer behalten ihre Konten, sofern sie nicht separat gesperrt oder deaktiviert werden.
• Die Föderation wird dadurch nicht deaktiviert. Benutzer auf anderen Heimservern können weiterhin mit lokalen Benutzern und Räumen kommunizieren, vorbehaltlich der Raumzugehörigkeit und der Föderationseinstellungen.
• Dadurch wird kein Raum nur auf Einladung zugänglich gemacht. Die Beitrittsregeln für Räume sind eine separate Einstellung; Registrierungstoken ersetzen keine Raumeinladungen.
• Es blockiert nicht zwangsläufig jeden Bereitstellungspfad. Admin-APIs, ein konfiguriertes gemeinsames Geheimnis, Anwendungsdienste und SSO-Kontoerstellungseinstellungen müssen separat geprüft werden.

Eine Reverse-Proxy-Regel, die eine Registrierungs-URL verbirgt, kann zwar eine zusätzliche Steuerungsmöglichkeit auf Netzwerkebene darstellen, birgt aber die Gefahr, Client-Abläufe zu unterbrechen und ersetzt nicht die Konfiguration des Homeservers. Verwenden Sie daher die Anwendungseinstellung als primäre Steuerungsmöglichkeit und testen Sie die tatsächliche Bereitstellung nach jeder Proxy-Änderung.

Ergebnis überprüfen

1. Prüfen Sie die effektive Konfigurationsquelle, einschließlich etwaiger Container-Bind-Mounts oder generierter Konfigurationen, auf die beabsichtigten Registrierungswerte.
2. Starten Sie Synapse neu und überprüfen Sie die Startprotokolle auf YAML-Fehler oder nicht unterstützte Einstellungen.
3. Versuchen Sie von einem abgemeldeten Matrix-Client aus, eine neue Registrierung zu starten. Wenn die Registrierung deaktiviert ist, sollte der Ablauf keine nutzbare öffentliche Registrierung anbieten. Wenn die tokenbasierte Registrierung aktiviert ist, sollte eine Anfrage ohne gültiges Token nicht abgeschlossen werden.
4. Testen Sie die Token-Registrierung mit einem temporären Einmal-Token und vergewissern Sie sich, dass nur ein Konto erstellt wird. Prüfen Sie die Antwort der Admin-API auf Informationen zu completedGültigkeitsdauer, Gültigkeitsdauer und Ablaufdatum.pending
5. Testen Sie einen separat konfigurierten SSO-Pfad und alle zugehörigen Skripte zur Kontobereitstellung. Stellen Sie sicher, dass diese sich gemäß Ihrer Zugriffsrichtlinie verhalten.

Verwenden Sie für ein Testkonto kein echtes Einladungstoken, es sei denn, Sie beabsichtigen, es auch tatsächlich zu verwenden. Falls die Einstellung keine Wirkung zeigt, überprüfen Sie zunächst, ob Sie die von Synapse geladene Datei geändert haben und ob der Dienst neu gestartet wurde. Prüfen Sie anschließend, ob ein gemeinsames Registrierungsgeheimnis, eine automatische SSO-Registrierung oder ein anderer vertrauenswürdiger Bereitstellungsmechanismus vorhanden ist.

Offizielle Referenzen

• Synapse 1.160 Konfigurationshandbuch: Registrierungseinstellungen
• Synapse-Registrierungstoken-Admin-API
• Synapse-Installationsanleitung: Benutzer registrieren
• Synapse-API zur Registrierung gemeinsamer Geheimnisse
• Matrix Client-Server API-Spezifikation

Die versionierte Konfiguration und die Dokumentation der Admin-API von Synapse sind die maßgebliche Quelle für Optionsnamen und Anfragefelder. Die obigen Anweisungen setzen kein bestimmtes Betriebssystem, Container-Image, Reverse-Proxy oder Matrix-Client voraus; überprüfen Sie diese umgebungsspezifischen Details, bevor Sie Änderungen anwenden.