Permiteți utilizatorilor aprobați să creeze Jitsi Rooms cu autentificarea Keycloak

Pentru a limita crearea de săli Jitsi Meet la anumite persoane, a solicita gazde autentificate și a emite acreditări doar conturilor aprobate. Pentru noile instalări auto-găzduite, Jitsi recomandă acum autentificarea bazată pe token-uri; acest ghid folosește Keycloak ca furnizor de identitate, permițând în același timp invitaților să se alăture sălilor numai după ce o gazdă aprobată le pornește.

1. Verificați implementarea și alegeți conturile gazdă

Aceste instrucțiuni vizează o instalare Jitsi Meet auto-găzduită din pachete Debian sau Ubuntu, cu acces de administrator la Prosody, Nginx și configurația web Jitsi. Presupune că Keycloak este deja instalat sau poate fi implementat în siguranță. Prosody este serverul de mesagerie XMPP; un JSON Web Token (JWT) este o acreditare semnată folosită pentru a dovedi că cineva s-a autentificat. Keycloak este un furnizor de identitate care gestionează conectarea utilizatorilor.

Manualul Jitsi marchează rețeta mai veche pentru domeniul securizat cu nume de utilizator și parolă ca fiind depreciată și indică noile instalări către autentificarea prin token-uri. Instrucțiunile actuale de autentificare au fost actualizate pe 5 octombrie 2026. Dacă utilizați deja Docker, nu copiați căile pachetelor de mai jos: ghidul oficial de configurare Docker utilizează variabile de mediu precum ENABLE_AUTH, ENABLE_GUESTS, și AUTH_TYPE.

Înainte de editare, notați numele gazdei întâlnirii publice, confirmați că HTTPS funcționează, faceți o copie de rezervă a fișierelor de configurare pe care intenționați să le modificați și decideți ce conturi denumite pot găzdui întâlniri. În acest exemplu, adresa întâlnirii este jitsi.example.com; înlocuiți-o peste tot cu gazda reală.

2. Acordați acces în Keycloak doar gazdelor aprobate

Creați un tărâm dedicat

În consola de administrare Keycloak, creați și selectați o zonă de nume jitsi-realm. O zonă este o colecție izolată de utilizatori și setări de aplicație. Dezactivați înregistrarea deschisă a utilizatorilor și evitați importul automat al unui director de companie nerestricționat: în cadrul acestei configurații, orice cont capabil să se autentifice la zona acceptată poate deveni creator de întâlniri.

Înregistrați clientul web Jitsi

Creați un client OpenID Connect numit jitsi. OpenID Connect (OIDC) este protocolul de conectare utilizat de Keycloak pentru a returna informații de identitate către Jitsi. Urmând exemplul oficial Jitsi, introduceți aceste valori exacte pentru apel invers, ajustând numele de gazdă:

• URI de redirecționare valid:https://jitsi.example.com/static/sso.html
• URI de redirecționare post-deconectare valid:https://jitsi.example.com/static/logout.html
• Origine web:https://jitsi.example.com

Adăugați persoanele permise

Sub Utilizatori, creați un cont pentru fiecare gazdă autorizată, apoi setați parola utilizatorului respectiv sub Acreditări. Folosiți conturi separate în loc să partajați un singur nume de utilizator de administrator. Un cont care nu mai trebuie să creeze întâlniri trebuie dezactivat sau i se va refuza autentificarea pentru această zonă. Dacă aveți nevoie de restricții doar pentru un grup dintr-o zonă partajată, adăugați o politică de autorizare verificată separat; pașii de aici nu impun automat apartenența la grupul Keycloak.

3. Conectați Keycloak la serverul Jitsi

Puncte finale proxy Keycloak realm prin HTTPS

Configurați Keycloak cu numele de gazdă public corect și anteturile reverse-proxy de încredere, apoi direcționați /realms/cererile de la numele dvs. de gazdă Jitsi către listener-ul său privat Keycloak. Pentru o instanță Keycloak disponibilă la 127.0.0.1:18080, adăugați următorul bloc de locație în cadrul blocului serverului HTTPS Jitsi Nginx existent, înainte de rutele Jitsi generale:

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

Aceasta presupune că Keycloak este accesibil local pe acel port; înlocuiți portul upstream pentru implementarea dvs. Nu expuneți consola de administrare sau portul backend al Keycloak în mod inutil. Consultați documentația Keycloak pentru proxy-ul invers pentru controalele proxy-ului de producție și ale numelui de gazdă.

Necesită jetoane în Prosody

Editați /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. Adăugați setările emitentului și publicului, apoi actualizați blocul principal existent VirtualHostpentru a utiliza autentificarea cu token-uri. Îmbinați aceste linii cu celelalte setări ale sale - nu creați o a doua copie a acelui bloc gazdă:

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"

Pentru accesul oaspetelui, adăugați o guest.jitsi.example.comgazdă virtuală separată cu authentication = "jitsi-anonymous", c2s_require_encryption = false, și smacksmodulul, așa cum se arată în instrucțiunile Jitsi. Acesta este un domeniu XMPP intern: nu creați DNS public sau un certificat separat pentru acesta. În lista de module a gazdei principale existente, adăugați persistent_lobby; în conference.jitsi.example.comlista de module a componentei MUC existente, adăugați muc_wait_for_host. Un MUC este componenta de chat multi-utilizator care întreține sălile de conferințe. Păstrați modulele deja listate.

Configurați fluxul de conectare în browser

În /etc/jitsi/meet/jitsi.example.com-config.js, adăugați anonymousdomain: 'guest.jitsi.example.com'la hostsobiectul existent. Adăugați setările OIDC documentate de 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" };

Aceste valori implementează fluxul de conectare prin cod de autorizare cu PKCE (Proof Key for Code Exchange), o protecție pentru autorizarea bazată pe browser. Manualul Jitsi spune în mod specific să lăsați jicofo.confautentificarea dezactivată pentru modul token; nu copiați blocul său de autentificare XMPP Secure Domain, care este învechit.

Validați și reîncărcați serviciile

Verificați sintaxa Nginx, apoi reporniți doar serviciile listate în instrucțiunile curente de autentificare a token-urilor. Efectuați aceste modificări într-o fereastră de mentenanță dacă serverul Jitsi este deja utilizat:

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

4. Evitați aceste greșeli de permisiuni și conectare

• Oricine poate în continuare să inițieze o cameră: confirmați că gazda principală Prosody este autentificată prin token, token-urile goale nu sunt permise și gazda invitată este separată. Testați într-o sesiune de browser curată, nu una care deține încă o autentificare validă.
• Utilizatorii aprobați nu se pot conecta: comparați emitentul realm-ului Keycloak, numele de gazdă HTTPS public, ID-ul clientului, URI-ul de redirecționare și Prosody cache_keys_url. O redirecționare eșuată a browserului nu este o dovadă că permisiunile utilizatorului sunt corecte.
• Oaspeții nu intră niciodată într-o cameră: verificați domeniul anonim atât în ​​Prosody, cât și în Jitsi config.js, plus modulele wait-for-host. O stare de așteptare pentru oaspeți în lobby sau este diferită de eșecul de autentificare.

5. Verificați cine poate crea o întâlnire nouă

Deschideți adresa URL a unei camere neutilizate niciodată într-o fereastră de navigare privată fără a vă conecta. Invitatul nu ar trebui să poată începe conferința ca prim gazdă. Apoi, conectați-vă ca utilizator Keycloak aprobat și creați camera respectivă; un invitat ar trebui să se poată alătura apoi dacă ați activat domeniul invitat. În cele din urmă, încercați un cont dezactivat sau neaprobat și confirmați că nu se poate autentifica, apoi creați o cameră nouă.

Dacă vreun test eșuează, inspectați-l sudo journalctl -u prosody -u nginx --since "10 minutes ago"alături de evenimentele de autentificare Keycloak, fără a publica token-uri sau parole din jurnale. Remedierea este confirmată numai atunci când un cont aprobat poate crea o cameră nouă, iar un utilizator neautentificat nu poate.