Genehmigten Benutzern die Erstellung von Jitsi-Räumen mit Keycloak-Anmeldung ermöglichen

Um die Erstellung von Jitsi Meet-Räumen auf bestimmte Personen zu beschränken, sollten authentifizierte Gastgeber erforderlich sein und Zugangsdaten nur an genehmigte Konten ausgegeben werden. Für neue, selbstgehostete Installationen empfiehlt Jitsi nun die tokenbasierte Authentifizierung. In dieser Anleitung wird Keycloak als Identitätsanbieter verwendet, und eingeladene Gäste können Räumen erst beitreten, nachdem ein genehmigter Gastgeber diese erstellt hat.

1. Überprüfen Sie die Bereitstellung und wählen Sie Ihre Hostkonten aus.

Diese Anleitung richtet sich an eine selbstgehostete Jitsi Meet-Installation aus Debian- oder Ubuntu-Paketen mit Administratorrechten für Prosody, Nginx und die Jitsi-Webkonfiguration. Sie setzt voraus, dass Keycloak bereits installiert ist oder sicher bereitgestellt werden kann. Prosody ist der XMPP-Messaging-Server; ein JSON Web Token (JWT) ist ein signiertes Berechtigungszertifikat, das die Authentifizierung eines Benutzers bestätigt. Keycloak ist ein Identitätsanbieter, der die Benutzeranmeldung verwaltet.

Das Jitsi-Handbuch kennzeichnet die ältere Secure-Domain-Methode mit Benutzername und Passwort als veraltet und verweist bei Neuinstallationen auf die Token-Authentifizierung. Die aktuellen Authentifizierungsanweisungen wurden am 5. Oktober 2026 aktualisiert. Wenn Sie bereits Docker verwenden, kopieren Sie die unten stehenden Paketpfade nicht: Die offizielle Docker-Konfigurationsanleitung verwendet Umgebungsvariablen wie z. B. `<docker-config.json>` ENABLE_AUTH, `<docker-config.json ENABLE_GUESTS>` und `<docker-config.json> AUTH_TYPE`.

Notieren Sie sich vor der Bearbeitung den Hostnamen Ihres öffentlichen Meetings, prüfen Sie die HTTPS-Verbindung, sichern Sie die zu ändernden Konfigurationsdateien und legen Sie fest, welche benannten Konten Meetings hosten dürfen. In diesem Beispiel lautet die Meeting-Adresse [Adresse jitsi.example.comeinfügen]; ersetzen Sie diese überall durch Ihre tatsächliche Hostadresse.

2. Gewähren Sie in Keycloak nur genehmigten Hosts Zugriff.

Erstelle einen dedizierten Bereich

Erstellen und wählen Sie in der Keycloak-Administrationskonsole einen Realm mit dem Namen „<Realm>“ jitsi-realm. Ein Realm ist eine isolierte Sammlung von Benutzern und Anwendungseinstellungen. Deaktivieren Sie die offene Benutzerregistrierung und verhindern Sie den automatischen Import eines uneingeschränkten Firmenverzeichnisses: In dieser Konfiguration kann jedes Konto, das sich im entsprechenden Realm authentifizieren kann, Besprechungen erstellen.

Registrieren Sie den Jitsi-Webclient

Erstellen Sie einen OpenID Connect-Client mit dem Namen „ jitsi<Clientname>“. OpenID Connect (OIDC) ist das Anmeldeprotokoll, das Keycloak verwendet, um Identitätsinformationen an Jitsi zurückzugeben. Geben Sie, dem offiziellen Jitsi-Beispiel folgend, genau diese Callback-Werte ein und passen Sie dabei den Hostnamen an:

• Gültige Umleitungs-URI:https://jitsi.example.com/static/sso.html
• Gültige Weiterleitungs-URI nach dem Ausloggen:https://jitsi.example.com/static/logout.html
• Webursprung:https://jitsi.example.com

Fügen Sie die zulässigen Personen hinzu.

Erstellen Sie unter „Benutzer“ für jeden autorisierten Host ein Konto und legen Sie anschließend dessen Passwort unter „Anmeldeinformationen“ fest. Verwenden Sie separate Konten, anstatt einen gemeinsamen Administrator-Login zu nutzen. Ein Konto, das keine Meetings mehr erstellen soll, muss deaktiviert oder die Authentifizierung für diesen Bereich verweigert werden. Falls Sie Einschränkungen nur für eine Gruppe innerhalb eines gemeinsam genutzten Bereichs benötigen, fügen Sie eine separat verifizierte Autorisierungsrichtlinie hinzu; die hier beschriebenen Schritte erzwingen die Keycloak-Gruppenmitgliedschaft nicht automatisch.

3. Verbinden Sie Keycloak mit dem Jitsi-Server.

Keycloak-Realm-Endpunkte über HTTPS weiterleiten

Konfigurieren Sie Keycloak mit dem korrekten öffentlichen Hostnamen und den entsprechenden Reverse-Proxy-Headern und leiten Sie anschließend /realms/Anfragen von Ihrem Jitsi-Hostnamen an den zugehörigen privaten Keycloak-Listener weiter. 127.0.0.1:18080Fügen Sie für eine Keycloak-Instanz, die unter <URL> erreichbar ist, den folgenden Location-Block innerhalb des bestehenden Jitsi-Nginx-HTTPS-Server-Blocks vor den allgemeinen Jitsi-Routen ein:

location ~ ^/realms/(.*) {
    proxy_pass http://127.0.0.1:18080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Dies setzt voraus, dass Keycloak lokal über diesen Port erreichbar ist; ersetzen Sie den Upstream-Port für Ihre Umgebung. Geben Sie die Administrationskonsole oder den Backend-Port von Keycloak nicht unnötigerweise frei. Informationen zu Proxy- und Hostnameneinstellungen für den Produktivbetrieb finden Sie in der Keycloak-Dokumentation zum Reverse-Proxy .

Tokens in Prosody benötigen

Bearbeiten /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. Fügen Sie die Aussteller- und Zielgruppeneinstellungen hinzu und aktualisieren Sie anschließend den bestehenden Hauptblock, VirtualHostum die Token-Authentifizierung zu verwenden. Führen Sie diese Zeilen mit den übrigen Einstellungen zusammen – erstellen Sie keine zweite Kopie dieses Hostblocks.

asap_accepted_issuers = { "https://jitsi.example.com/realms/jitsi-realm" }
asap_accepted_audiences = { "account" }
asap_require_room_claim = false

VirtualHost "jitsi.example.com"
    authentication = "token"
    app_id = "jitsi"
    allow_empty_token = false
    cache_keys_url = "https://jitsi.example.com/realms/jitsi-realm/protocol/openid-connect/certs"

Für den Gastzugriff fügen Sie einen separaten guest.jitsi.example.comvirtuellen Host mit den Modulen `<virtual host>` authentication = "jitsi-anonymous", `<virtual host c2s_require_encryption = false>` und ` <module>` hinzu smacks, wie in der Jitsi-Anleitung beschrieben. Dies ist eine interne XMPP-Domäne: Erstellen Sie dafür keinen öffentlichen DNS-Server und kein separates Zertifikat. Fügen Sie in der Modulliste des bestehenden Haupthosts das Modul `<virtual host>` hinzu ; fügen Sie in der Modulliste der persistent_lobbybestehenden MUC-Komponente das Modul `<module>` hinzu . Ein MUC (Multi-User Chat Component) verwaltet Konferenzräume. Die bereits aufgeführten Module bleiben erhalten.conference.jitsi.example.commuc_wait_for_host

Konfigurieren Sie den Anmeldevorgang im Browser.

/etc/jitsi/meet/jitsi.example.com-config.jsFügen Sie in anonymousdomain: 'guest.jitsi.example.com'dem bestehenden hostsObjekt die von Jitsi dokumentierten OIDC-Einstellungen hinzu:

config.tokenAuthUrl='https://'+ config.hosts.domain + '/realms/jitsi-realm/protocol/openid-connect/auth?client_id=jitsi&response_type=code&scope=openid&state={state}&redirect_uri=https://'+ config.hosts.domain + '/static/sso.html&code_challenge={code_challenge}&code_challenge_method=S256';
config.tokenLogoutUrl='https://'+ config.hosts.domain + '/realms/jitsi-realm/protocol/openid-connect/logout?post_logout_redirect_uri=https://'+ config.hosts.domain + '/static/logout.html';
config.tokenAuthInline=true;
config.sso={ ssoService: config.hosts.domain, tokenService: config.hosts.domain + '/realms/jitsi-realm/protocol/openid-connect', clientId: "jitsi" };

Diese Werte implementieren den Anmeldevorgang mit Autorisierungscode und PKCE (Proof Key for Code Exchange), einem Schutzmechanismus für die browserbasierte Autorisierung. Das Jitsi-Handbuch empfiehlt ausdrücklich, jicofo.confdie Authentifizierung im Token-Modus deaktiviert zu lassen; der veraltete Authentifizierungsblock für XMPP Secure Domain sollte nicht kopiert werden.

Dienste überprüfen und neu laden

Überprüfen Sie die Nginx-Syntax und starten Sie anschließend nur die in den aktuellen Token-Authentifizierungsanweisungen aufgeführten Dienste neu. Führen Sie diese Änderungen in einem Wartungsfenster durch, falls Ihr Jitsi-Server bereits in Betrieb ist.

sudo nginx -t
sudo systemctl restart prosody
sudo systemctl restart nginx

4. Vermeiden Sie diese Berechtigungs- und Anmeldefehler.

• Jeder kann weiterhin einen Raum starten: Stellen Sie sicher, dass der Haupt-Prosody-Host tokenbasiert authentifiziert ist, leere Tokens nicht zulässig sind und der Gast-Host separat ist. Testen Sie dies in einer neuen Browsersitzung, nicht in einer, die noch eine gültige Anmeldung enthält.
• Genehmigte Benutzer können sich nicht anmelden: Vergleichen Sie den Keycloak-Realm-Aussteller, den öffentlichen HTTPS-Hostnamen, die Client-ID, die Umleitungs-URI und die Prosody cache_keys_url. Eine fehlgeschlagene Browser-Umleitung ist kein Beweis dafür, dass die Benutzerberechtigungen korrekt sind.
• Gäste betreten niemals einen Raum: Überprüfen Sie die anonyme Domäne sowohl in Prosody als auch in Jitsi config.jssowie die Module „Warten auf den Gastgeber“. Ein Lobby- oder Gästewartezustand ist etwas anderes als ein Authentifizierungsfehler.

5. Überprüfen Sie, wer ein neues Meeting erstellen kann.

Öffnen Sie eine noch nie verwendete Raum-URL in einem privaten Browserfenster, ohne sich anzumelden. Der Gast sollte die Konferenz nicht als erster Gastgeber starten können. Melden Sie sich anschließend als autorisierter Keycloak-Benutzer an und erstellen Sie diesen Raum. Ein eingeladener Gast sollte dann beitreten können, sofern Sie die Gastdomäne aktiviert haben. Testen Sie abschließend ein deaktiviertes oder nicht autorisiertes Konto und bestätigen Sie, dass die Authentifizierung und die Erstellung eines neuen Raums fehlschlagen.

Falls ein Test fehlschlägt, überprüfen Sie sudo journalctl -u prosody -u nginx --since "10 minutes ago"die Keycloak-Authentifizierungsereignisse, ohne dabei Tokens oder Passwörter aus den Protokollen zu veröffentlichen. Die Fehlerbehebung gilt erst dann als bestätigt, wenn ein autorisiertes Konto einen neuen Raum erstellen kann, ein nicht authentifizierter Benutzer jedoch nicht.