Umożliw zatwierdzonym użytkownikom tworzenie pokoi Jitsi z logowaniem przez Keycloak

Aby ograniczyć tworzenie pokoi w Jitsi Meet do konkretnych osób, należy wymagać uwierzytelnionych gospodarzy i wydawać dane uwierzytelniające tylko zatwierdzonym kontom. W przypadku nowych instalacji hostowanych samodzielnie, Jitsi zaleca teraz uwierzytelnianie oparte na tokenie; niniejszy przewodnik używa Keycloak jako dostawcy tożsamości, a zaproszeni goście mogą dołączać do pokoi dopiero po ich uruchomieniu przez zatwierdzonego gospodarza.

1. Sprawdź wdrożenie i wybierz konta hosta

Te instrukcje dotyczą instalacji Jitsi Meet hostowanej samodzielnie z pakietów Debian lub Ubuntu, z dostępem administratora do Prosody, Nginx i konfiguracji sieciowej Jitsi. Zakładają one, że Keycloak jest już zainstalowany lub można go bezpiecznie wdrożyć. Prosody to serwer komunikatów XMPP; token JSON Web Token (JWT) to podpisane dane uwierzytelniające, które potwierdzają uwierzytelnienie użytkownika. Keycloak to dostawca tożsamości, który obsługuje logowanie użytkowników.

W podręczniku Jitsi starszy przepis na bezpieczną domenę z nazwą użytkownika i hasłem jest uznany za przestarzały i wskazuje nowym instalacjom uwierzytelnianie tokenem. Aktualne instrukcje uwierzytelniania zostały zaktualizowane 5 października 2026 r. Jeśli korzystasz już z Dockera, nie kopiuj poniższych ścieżek pakietów: oficjalny przewodnik konfiguracji Dockera używa zmiennych środowiskowych, takich jak ENABLE_AUTH, ENABLE_GUESTS, i AUTH_TYPE.

Przed edycją zanotuj nazwę hosta spotkania publicznego, sprawdź, czy protokół HTTPS działa, utwórz kopię zapasową plików konfiguracyjnych, które planujesz zmienić, i zdecyduj, które konta mogą być gospodarzami spotkań. W tym przykładzie adres spotkania to jitsi.example.com; zastąp go wszędzie nazwą swojego hosta.

2. Udzielaj dostępu do Keycloak tylko zatwierdzonym hostom

Utwórz dedykowane królestwo

W konsoli administracyjnej Keycloak utwórz i wybierz domenę o nazwie jitsi-realm. Domena to wyizolowany zbiór ustawień użytkowników i aplikacji. Wyłącz otwartą rejestrację użytkowników i unikaj automatycznego importowania nieograniczonego katalogu firmowego: w tej konfiguracji każde konto, które może uwierzytelnić się w zaakceptowanej domenie, może zostać twórcą spotkania.

Zarejestruj klienta internetowego Jitsi

Utwórz klienta OpenID Connect o nazwie jitsi. OpenID Connect (OIDC) to protokół logowania używany przez Keycloak do zwracania informacji o tożsamości do Jitsi. Postępując zgodnie z oficjalnym przykładem Jitsi, wprowadź te dokładne wartości wywołania zwrotnego, dostosowując nazwę hosta:

• Prawidłowy adres URI przekierowania:https://jitsi.example.com/static/sso.html
• Prawidłowy adres URI przekierowania po wylogowaniu:https://jitsi.example.com/static/logout.html
• Źródło internetowe:https://jitsi.example.com

Dodaj uprawnione osoby

W sekcji Użytkownicy utwórz konto dla każdego autoryzowanego hosta, a następnie ustaw hasło tego użytkownika w sekcji Poświadczenia. Używaj oddzielnych kont zamiast udostępniać jeden login administratora. Konto, które nie powinno już tworzyć spotkań, musi być wyłączone lub musi mieć zablokowane uwierzytelnianie w tej domenie. Jeśli potrzebujesz ograniczeń tylko dla jednej grupy w domenie współdzielonej, dodaj oddzielnie zweryfikowaną politykę autoryzacji; kroki opisane w tym artykule nie wymuszają automatycznie członkostwa w grupie Keycloak.

3. Połącz Keycloak z serwerem Jitsi

Punkty końcowe domeny proxy Keycloak przez HTTPS

Skonfiguruj Keycloak z poprawną publiczną nazwą hosta i zaufanymi nagłówkami odwrotnego proxy, a następnie kieruj /realms/żądania z nazwy hosta Jitsi do jego prywatnego nasłuchiwacza Keycloak. Aby instancja Keycloak była dostępna pod adresem 127.0.0.1:18080, dodaj następujący blok lokalizacji w istniejącym bloku serwera HTTPS Jitsi Nginx, przed ogólnymi trasami Jitsi:

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;
}

Zakłada się, że Keycloak jest dostępny lokalnie na tym porcie; zastąp port upstream dla swojego wdrożenia. Nie udostępniaj niepotrzebnie konsoli administracyjnej Keycloak ani portu zaplecza. Sprawdź dokumentację odwrotnego proxy Keycloak , aby uzyskać informacje o kontroli proxy produkcyjnego i nazw hostów.

Wymagaj tokenów w Prosody

Edytuj /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. Dodaj ustawienia wystawcy i odbiorców, a następnie zaktualizuj istniejący plik główny VirtualHost, aby korzystał z uwierzytelniania tokenem. Połącz te wiersze z pozostałymi ustawieniami — nie twórz drugiej kopii tego bloku hosta:

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"

Aby uzyskać dostęp dla gości, dodaj osobnego guest.jitsi.example.comhosta wirtualnego za pomocą authentication = "jitsi-anonymous", c2s_require_encryption = falsei smacksmodułu, zgodnie z instrukcjami Jitsi. Jest to wewnętrzna domena XMPP: nie twórz dla niej publicznego DNS ani osobnego certyfikatu. Na liście modułów istniejącego hosta głównego dodaj persistent_lobby; na conference.jitsi.example.comliście modułów istniejącego komponentu MUC dodaj muc_wait_for_host. MUC to wielodostępny komponent czatu, który zarządza pokojami konferencyjnymi. Zachowaj moduły, które zostały już wymienione.

Skonfiguruj przepływ logowania w przeglądarce

W /etc/jitsi/meet/jitsi.example.com-config.js, dodaj anonymousdomain: 'guest.jitsi.example.com'do istniejącego hostsobiektu. Dołącz ustawienia OIDC udokumentowane przez Jitsi:

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" };

Te wartości implementują przepływ logowania z kodem autoryzacyjnym za pomocą PKCE (Proof Key for Code Exchange), zabezpieczenia autoryzacji w przeglądarce. Podręcznik Jitsi wyraźnie zaleca pozostawienie jicofo.confuwierzytelniania wyłączonego w trybie tokena; nie należy kopiować przestarzałego bloku uwierzytelniania XMPP Secure Domain.

Sprawdź poprawność i ponownie załaduj usługi

Sprawdź składnię Nginx, a następnie uruchom ponownie tylko usługi wymienione w bieżących instrukcjach uwierzytelniania tokenem. Wprowadź te zmiany w oknie konserwacji, jeśli serwer Jitsi jest już używany:

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

4. Unikaj tych błędów związanych z uprawnieniami i logowaniem

• Każdy nadal może założyć pokój: sprawdź, czy główny host Prosody jest uwierzytelniony tokenem, puste tokeny są niedozwolone, a host gościnny jest oddzielny. Przetestuj w czystej sesji przeglądarki, a nie w takiej, która nadal zawiera ważne dane logowania.
• Zatwierdzeni użytkownicy nie mogą się zalogować: porównaj wystawcę domeny Keycloak, publiczną nazwę hosta HTTPS, identyfikator klienta, adres URI przekierowania i Prosody cache_keys_url. Nieudane przekierowanie przeglądarki nie jest dowodem na poprawność uprawnień użytkownika.
• Goście nigdy nie wchodzą do pokoju: sprawdź domenę anonimową w Prosody i Jitsi config.js, a także moduły oczekiwania na hosta. Stan oczekiwania w poczekalni lub gościa różni się od niepowodzenia uwierzytelnienia.

5. Sprawdź, kto może utworzyć nowe spotkanie

Otwórz adres URL nigdy nieużywanego pokoju w oknie przeglądania prywatnego bez logowania. Gość nie powinien móc rozpocząć konferencji jako jej pierwszy gospodarz. Następnie zaloguj się jako zatwierdzony użytkownik Keycloak i utwórz ten pokój; zaproszony gość powinien móc dołączyć, jeśli włączono domenę gościa. Na koniec spróbuj użyć wyłączonego lub niezatwierdzonego konta i potwierdź, że nie można go uwierzytelnić, a następnie utwórz nowy pokój.

Jeśli którykolwiek z testów zakończy się niepowodzeniem, należy przeprowadzić inspekcję sudo journalctl -u prosody -u nginx --since "10 minutes ago"równolegle ze zdarzeniami uwierzytelniania Keycloak, bez publikowania tokenów ani haseł z logów. Naprawa zostanie potwierdzona tylko wtedy, gdy zatwierdzone konto będzie mogło utworzyć nowy pokój, a niezautoryzowany użytkownik nie będzie mógł.