Wie man die Erstellung von Jitsi-Räumen auf bestimmte authentifizierte Benutzer beschränkt

Stand 6. Oktober 2026 unterstützt das aktuelle Jitsi-Handbuch für Self-Hosting weiterhin das Ziel, dass nur authentifizierte Benutzer Konferenzräume erstellen können, Gäste aber später beitreten können. Das Handbuch kennzeichnet das ältere Verfahren „Sichere Domäne“ jedoch für Neuinstallationen als veraltet und empfiehlt stattdessen die tokenbasierte Authentifizierung. Die richtige Konfiguration hängt von der Installationsmethode von Jitsi ab: Diese Anleitung beschreibt den direkten Weg zur internen Authentifizierung für Docker-Bereitstellungen und erläutert die aktuelle Vorgehensweise für Neuinstallationen unter Debian oder Ubuntu.

Diese Einstellungen regeln, wer einen Chatraum erstellen kann. Sie machen nicht automatisch jeden Chatraum privat. Chatraumpasswörter, die Lobby und der Einladungsprozess sind separate Einstellungen.

Wählen Sie einen Authentifizierungspfad

Die aktuelle Jitsi-Authentifizierungsanleitung beschreibt die Erstellung authentifizierter Räume mit anonymen Gästen. Auf der älteren Seite „Sichere Domäne“ wird ausdrücklich darauf hingewiesen, dass diese Methode für Neuinstallationen veraltet ist. Vermeiden Sie es, alte Prosody- oder Jicofo-Einstellungen in eine neuere Installation zu kopieren, ohne vorher die Anleitung zu konsultieren, die zu Ihrer Installationsmethode passt.

Docker: Nur bereitgestellten Benutzern das Starten von Räumen erlauben

Diese Vorgehensweise setzt voraus, dass Sie Jitsi Meet bereits über das offizielle Docker Compose-Projekt ausführen und dessen .envKonfigurationsdatei bearbeiten können. Das folgende Beispiel verwendet den integrierten internalAuthentifizierungsmodus. Es wird keine öffentliche Registrierungsseite hinzugefügt: Ein Administrator erstellt und löscht die zulässigen Benutzerkonten.

1. Aktivieren Sie die Authentifizierung in der Umgebungsdatei.

Öffnen Sie die .envDatei, die von Ihrer Jitsi Compose-Bereitstellung verwendet wird. Legen Sie die Authentifizierungsvariablen wie folgt fest:

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

Stellen Sie sicher, dass die Zeilen aktive Einstellungen und keine Kommentare sind, die mit einem Punkt beginnen #. Mit dieser ENABLE_GUESTS=1Einstellung können Personen, die nicht angemeldet sind, als Gäste beitreten, nachdem ein authentifizierter Benutzer die Konferenz geöffnet hat. Wenn sich jeder Teilnehmer authentifizieren soll, setzen Sie die Einstellung auf „aktiv“ ENABLE_GUESTS=0. Dadurch wird festgelegt, wer beitreten darf, nicht nur, wer Räume erstellen darf.

Die Docker-Dokumentation beschreibt diese Variablen und den integrierten Konto-Workflow. Die aktuelle Liste der unterstützten Authentifizierungstypen und -optionen finden Sie im Abschnitt „Authentifizierung“ für Docker .

2. Konfiguration anwenden

Wenden Sie die aktualisierte Umgebung aus dem Verzeichnis an, das Ihre Compose-Datei enthält. Compose erstellt die Dienste neu, deren Konfiguration sich geändert hat:

docker compose up -d

Prüfen Sie, ob die Container ausgeführt werden, bevor Sie Konten erstellen. Wenn Sie ein angepasstes Compose-Projekt, einen anderen Projektnamen oder eine Orchestrierungsschicht verwenden, führen Sie das entsprechende Update für diese Bereitstellung aus, anstatt einen zweiten Jitsi-Stack zu starten.

3. Erstellen Sie für jeden genehmigten Zimmerverwalter ein Konto.

Öffnen Sie eine Shell im Prosody-Container:

docker compose exec prosody /bin/bash

Registrieren Sie anschließend einen Jitsi-Benutzer in der standardmäßigen Docker-XMPP-Domäne:

prosodyctl --config /run/prosody/config/prosody.cfg.lua register <username> meet.jitsi <strong-password>

Ersetzen Sie beide Platzhalter durch den Benutzernamen und ein eindeutiges Passwort für diese Person. Lassen Sie die spitzen Klammern weg. Führen Sie den Befehl für einen zweiten autorisierten Host mit einem anderen Benutzernamen erneut aus. Der gezeigte Befehl verwendet die Standard-Docker-Domäne meet.jitsi; falls Sie diese geändert haben XMPP_DOMAIN, verwenden Sie die in Ihrer Bereitstellung konfigurierte Domäne. Die aktuelle Docker-Anleitung beschreibt den Befehl zum Entfernen des Prosody-Containers sowie den zugehörigen Befehl zum Entfernen des Containers.

Um einen Benutzer zu widerrufen, wechseln Sie in den Prosody-Container und führen Sie folgenden Befehl aus:

prosodyctl --config /run/prosody/config/prosody.cfg.lua unregister <username> meet.jitsi

Die Liste der Teilnehmer sollte auf Personen beschränkt sein, die Konferenzen initiieren können sollen. Ein Raumname ist kein Zugriffskontrollmechanismus, und der Zugriff auf ein Konto sollte entfernt werden, sobald der Gastgeber ihn nicht mehr benötigt.

4. Testen Sie die Host- und Gastpfade separat.

Verwenden Sie ein privates Browserfenster oder ein separates Browserprofil, damit eine bestehende Jitsi-Anmeldesitzung das Ergebnis nicht verdeckt. Öffnen Sie die öffentliche Jitsi-URL und versuchen Sie, einen neuen Raum ohne Authentifizierung zu starten. Die Instanz sollte eine Authentifizierung erfordern, bevor die neue Konferenz zugewiesen wird. Melden Sie sich mit einem Ihrer erstellten Konten an und starten Sie einen Raum; überprüfen Sie anschließend, ob der Raum geöffnet wird.

Öffnen Sie anschließend den Raumlink in einer separaten, nicht authentifizierten Browsersitzung. Bei aktiviertem Gastzugriff sollte der Gast der Konferenz beitreten können, sobald der authentifizierte Host sie startet. Laut Jitsis Docker-Anleitung müssen nicht authentifizierte Benutzer warten, bis sich ein Benutzer authentifiziert hat, wenn der Gastzugriff aktiviert ist.

Verwenden Sie für Neuinstallationen von Debian oder Ubuntu die aktuelle Anleitung zur Token-Authentifizierung.

Das aktuelle Handbuch für Jitsi Self-Hosting beschreibt einen neueren Authentifizierungspfad mit Token-Authentifizierung. Das dokumentierte Beispiel verbindet Jitsi mit Keycloak, konfiguriert den Prosody-Host für die Token-Abfrage und fügt eine anonyme Gastdomain hinzu, wenn Gäste zugelassen werden sollen. In der Jitsi-Konfiguration verwendet das dokumentierte Setup authentication = "token"für allow_empty_token = falseden Haupthost die Domains `/example.com` und `/example.com` und ordnet die Gastdomain `/example.com` zu jitsi-anonymous. Folgen Sie der vollständigen Authentifizierungsanleitung für den Keycloak-Realm, Client-Redirect-URLs, Reverse-Proxy-Routing, Prosody und die Jitsi-Webclient-Einstellungen. Ersetzen Sie alle Beispiel-Hostnamen durch Ihre eigenen und schützen Sie den Identity-Provider-Endpunkt mit HTTPS.

Die Token-Authentifizierung ist sinnvoll, wenn Konten von einem Identitätsanbieter verwaltet werden sollen oder Ihre Anwendung raumspezifische Zugriffstoken ausgibt. Sie erfordert einen korrekt konfigurierten Aussteller und eine korrekte Token-Validierung; die einfache Aktivierung einer Browsereinstellung schränkt die Raumerstellung nicht sicher ein. Falls Sie LDAP-basierte Konten mit Docker benötigen, beschreibt die Docker-Anleitung auch einen LDAP-Modus. Die LDAP-Verbindungs-, Zertifikats- und Filtereinstellungen müssen jedoch mit Ihrem Verzeichnis übereinstimmen.

Die Raumgestaltung ist etwas anderes als die Privatsphäre im Raum.

Die Authentifizierung beantwortet die Frage „Wer kann eine Konferenz starten?“. Sie beantwortet jedoch nicht automatisch die Frage „Wer darf diesem Raum beitreten?“. Wenn Gäste zugelassen sind, kann jeder, der die Raum-URL erhält, versuchen, beizutreten. Fügen Sie ein Raumpasswort hinzu oder konfigurieren Sie die Lobby für Meetings, zu denen nur eingeladene Teilnehmer zugelassen werden sollen. Jitsis Anleitung zum Selbsthosting unterscheidet zwischen der serverseitigen Möglichkeit, Konferenzen zu starten, und den Zugriffskontrollen, die in einem einzelnen Raum verwaltet werden.

Häufige Probleme, die Sie überprüfen sollten

• Die Erstellung von Räumen funktioniert weiterhin anonym: Überprüfen Sie, ENABLE_AUTH=1ob in der Umgebungsdatei, die vom laufenden Compose-Projekt verwendet wird, ob die Konfiguration aktiv ist, und wenden Sie die Konfiguration anschließend erneut an.
• Jeder Teilnehmer erhält eine Anmeldeaufforderung: Prüfen Sie, ob ENABLE_GUESTSdiese deaktiviert ist. Diese Einstellung erfordert die Authentifizierung der Teilnehmer; sie ist nicht erforderlich, wenn Sie authentifizierte Gastgeber mit Gastteilnehmern wünschen.
• Ein neues Konto kann sich nicht anmelden: Überprüfen Sie, ob Sie es in der für Ihre Bereitstellung konfigurierten Domäne registriert haben. Der Standardbefehl von Docker verwendet meet.jitsi; benutzerdefinierte XMPP-Domänen benötigen entsprechende Werte.
• Gäste können den Raum erst betreten, nachdem der Gastgeber ihn geöffnet hat: Dies entspricht dem Verhalten beim Gastzugang. Der authentifizierte Gastgeber sollte den Raum zuerst starten und die Gäste anschließend bitten, den Raumlink zu verwenden.
• Gemäß einer Anleitung für eine andere Installationsart sollten Sie Debian-Paketpfade, Docker-generierte Konfigurationen und ältere Secure-Domain-Snippets nicht vermischen. Verwenden Sie den Abschnitt im Handbuch für Ihre Installation und beachten Sie die Hinweise zu veralteten Funktionen.

Prüfliste

1. Ein nicht authentifizierter Browser kann keinen neuen Raum erstellen.
2. Ein berechtigter Benutzer kann sich anmelden und einen Raum starten.
3. Ein gelöschtes Konto kann sich nicht mehr authentifizieren.
4. Das Beitreten von Gästen verhält sich wie in Ihrer ENABLE_GUESTSKonfiguration vorgesehen.
5. Für private Besprechungen wird gegebenenfalls ein Raumpasswort oder eine Lobbyrichtlinie verwendet.

Die wichtigste Entscheidung ist, ob Ihre Jitsi-Instanz individuell bereitgestellte interne Konten oder Tokens eines Identitätsanbieters verwenden soll. Bei einer bestehenden Docker-Compose-Bereitstellung ist die interne Authentifizierung eine direkte Möglichkeit, die Erstellung von Räumen auf die wenigen registrierten Benutzer zu beschränken. Bei einer Neuinstallation sollten Sie mit der aktuellen Anleitung zur Token-Authentifizierung beginnen und die Zugriffskontrollen auf Raumebene separat konfigurieren.

Offizielle Referenzen

• Jitsi Meet: Authentifizierung (aktuelle Anleitung; zuletzt aktualisiert am 5. Oktober 2026)
• Jitsi Meet: Leitfaden zum Selbsthosting — Docker
• Jitsi Meet: Einrichtung einer sicheren Domäne (für Neuinstallationen als veraltet gekennzeichnet)
• Jitsi Meet: Leitfaden zum Selbsthosting — Debian/Ubuntu