Consenti agli utenti autorizzati di creare stanze Jitsi con l'accesso tramite Keycloak.

Per limitare la creazione di stanze Jitsi Meet a persone specifiche, è necessario richiedere host autenticati e rilasciare le credenziali solo agli account approvati. Per le nuove installazioni self-hosted, Jitsi ora consiglia l'autenticazione basata su token; questa guida utilizza Keycloak come provider di identità, consentendo agli ospiti invitati di accedere alle stanze solo dopo che un host approvato le ha avviate.

1. Verifica la distribuzione e scegli i tuoi account host

Queste istruzioni si riferiscono a un'installazione di Jitsi Meet self-hosted da pacchetti Debian o Ubuntu, con accesso amministrativo a Prosody, Nginx e alla configurazione web di Jitsi. Si presuppone che Keycloak sia già installato o possa essere distribuito in modo sicuro. Prosody è il server di messaggistica XMPP; un JSON Web Token (JWT) è una credenziale firmata utilizzata per dimostrare l'autenticazione di un utente. Keycloak è un provider di identità che gestisce l'accesso degli utenti.

Il manuale di Jitsi contrassegna la vecchia procedura di autenticazione Secure Domain con nome utente e password come obsoleta e indirizza le nuove installazioni all'autenticazione tramite token. Le istruzioni di autenticazione attuali sono state aggiornate il 5 ottobre 2026. Se si utilizza già Docker, non copiare i percorsi dei pacchetti riportati di seguito: la guida ufficiale alla configurazione di Docker utilizza variabili d'ambiente come ENABLE_AUTH, ENABLE_GUESTS, e AUTH_TYPE.

Prima di apportare modifiche, annota il nome host della tua riunione pubblica, verifica che HTTPS funzioni, esegui il backup dei file di configurazione che intendi modificare e decidi quali account denominati possono ospitare riunioni. In questo esempio, l'indirizzo della riunione è jitsi.example.com; sostituiscilo ovunque con il tuo host effettivo.

2. Concedi l'accesso in Keycloak solo agli host approvati.

Crea un regno dedicato

Nella console di amministrazione di Keycloak, crea e seleziona un realm denominato jitsi-realm. Un realm è una raccolta isolata di utenti e impostazioni dell'applicazione. Disabilita la registrazione aperta degli utenti ed evita l'importazione automatica di una directory aziendale senza restrizioni: con questa configurazione, qualsiasi account in grado di autenticarsi nel realm accettato può diventare un creatore di riunioni.

Registra il client web Jitsi

Crea un client OpenID Connect denominato jitsi. OpenID Connect (OIDC) è il protocollo di accesso utilizzato da Keycloak per restituire le informazioni di identità a Jitsi. Seguendo l'esempio ufficiale di Jitsi, inserisci esattamente questi valori di callback, adattando il nome host:

• URI di reindirizzamento valido:https://jitsi.example.com/static/sso.html
• URI di reindirizzamento post-logout valido:https://jitsi.example.com/static/logout.html
• Origine web:https://jitsi.example.com

Aggiungi le persone autorizzate

Nella sezione Utenti, crea un account per ogni host autorizzato, quindi imposta la password di tale utente nella sezione Credenziali. Utilizza account separati anziché condividere un unico login amministratore. Un account che non deve più creare riunioni deve essere disabilitato o, in alternativa, deve essere negata l'autenticazione a questo realm. Se hai bisogno di restrizioni solo per un gruppo all'interno di un realm condiviso, aggiungi una policy di autorizzazione verificata separatamente; i passaggi qui descritti non impongono automaticamente l'appartenenza al gruppo Keycloak.

3. Connetti Keycloak al server Jitsi

Proxy per gli endpoint del realm di Keycloak tramite HTTPS

Configura Keycloak con il nome host pubblico corretto e le intestazioni proxy inverso attendibili, quindi instrada /realms/le richieste dal tuo nome host Jitsi al relativo listener privato di Keycloak. Per un'istanza di Keycloak disponibile all'indirizzo 127.0.0.1:18080, aggiungi il seguente blocco location all'interno del blocco server HTTPS Nginx di Jitsi esistente, prima delle route generali di 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;
}

Questo presuppone che Keycloak sia raggiungibile localmente su quella porta; sostituisci l'indirizzo upstream con quello della tua implementazione. Non esporre inutilmente la console di amministrazione o la porta backend di Keycloak. Consulta la documentazione di Keycloak relativa al reverse proxy per i controlli del proxy di produzione e del nome host.

Richiede token in Prosody

Modifica /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. Aggiungi le impostazioni dell'emittente e del pubblico, quindi aggiorna il file principale esistente VirtualHostper utilizzare l'autenticazione tramite token. Unisci queste righe con le altre impostazioni: non creare una seconda copia di quel blocco host.

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"

Per l'accesso degli ospiti, aggiungere un guest.jitsi.example.comhost virtuale separato con authentication = "jitsi-anonymous", c2s_require_encryption = false, e il smacksmodulo, come mostrato nelle istruzioni di Jitsi. Questo è un dominio XMPP interno: non creare un DNS pubblico o un certificato separato per esso. Nell'elenco dei moduli dell'host principale esistente, aggiungere persistent_lobby; nell'elenco dei moduli del componente MUC esistente conference.jitsi.example.com, aggiungere muc_wait_for_host. Un MUC è il componente di chat multiutente che gestisce le sale conferenze. Mantenere i moduli già elencati.

Configura il flusso di accesso del browser

In /etc/jitsi/meet/jitsi.example.com-config.js, aggiungi anonymousdomain: 'guest.jitsi.example.com'all'oggetto esistente hosts. Aggiungi le impostazioni OIDC documentate da 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" };

Questi valori implementano il flusso di accesso tramite codice di autorizzazione con PKCE (Proof Key for Code Exchange), una protezione per l'autorizzazione basata su browser. Il manuale di Jitsi specifica di lasciare jicofo.confl'autenticazione disabilitata per la modalità token; non copiare il blocco di autenticazione XMPP Secure Domain obsoleto.

Convalida e ricarica i servizi

Verifica la sintassi di Nginx, quindi riavvia solo i servizi elencati nelle istruzioni di autenticazione tramite token correnti. Esegui queste modifiche durante una finestra di manutenzione se il tuo server Jitsi è già in uso:

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

4. Evita questi errori di autorizzazione e accesso

• Chiunque può ancora avviare una stanza: verificare che l'host principale di Prosody sia autenticato tramite token, che i token vuoti non siano consentiti e che l'host ospite sia separato. Eseguire il test in una sessione del browser pulita, non in una sessione che contenga ancora un login valido.
• Gli utenti autorizzati non possono accedere: confronta l'emittente del realm Keycloak, il nome host HTTPS pubblico, l'ID client, l'URI di reindirizzamento e Prosody cache_keys_url. Un reindirizzamento del browser non riuscito non è prova che le autorizzazioni dell'utente siano corrette.
• Gli ospiti non entrano mai in una stanza: verifica il dominio anonimo sia in Prosody che in Jitsi config.js, oltre ai moduli wait-for-host. Uno stato di attesa nella lobby o per gli ospiti è diverso da un errore di autenticazione.

5. Verifica chi può creare una nuova riunione

Apri l'URL di una stanza mai utilizzata prima in una finestra di navigazione in incognito, senza effettuare l'accesso. L'ospite non dovrebbe essere in grado di avviare la conferenza come primo host. Successivamente, accedi come utente Keycloak autorizzato e crea la stanza; a quel punto, un ospite invitato dovrebbe essere in grado di partecipare se hai abilitato il dominio per gli ospiti. Infine, prova con un account disabilitato o non autorizzato e verifica che non riesca ad autenticarsi e a creare una nuova stanza.

Se un test fallisce, esaminare sudo journalctl -u prosody -u nginx --since "10 minutes ago"insieme gli eventi di autenticazione di Keycloak, senza pubblicare token o password dai log. La correzione è confermata solo quando un account autorizzato può creare una nuova stanza e un utente non autenticato non può.