Come limitare la creazione di stanze Jitsi a specifici utenti autenticati

Al 6 ottobre 2026, il manuale di Jitsi per l'hosting autonomo continua a supportare l'obiettivo di consentire la creazione di sale conferenze solo agli utenti autenticati, permettendo agli ospiti di accedervi successivamente. Tuttavia, il manuale ora indica la precedente procedura "Secure Domain" come obsoleta per le nuove installazioni e raccomanda invece l'autenticazione basata su token. La configurazione corretta dipende da come è stato installato Jitsi: questa guida fornisce un percorso di autenticazione interna diretta per le implementazioni Docker e spiega la direzione attuale per le nuove installazioni su Debian o Ubuntu.

Questi controlli regolano chi può avviare una stanza. Non rendono automaticamente private tutte le stanze. Le password delle stanze, la lobby e il processo di invito sono gestiti da controlli separati.

Scegli un percorso di autenticazione

La guida di autenticazione Jitsi attualmente in uso descrive la creazione di stanze autenticate con ospiti anonimi, mentre la vecchia pagina relativa al dominio sicuro specifica esplicitamente che tale metodo è obsoleto per le nuove installazioni. Evitate di copiare le vecchie impostazioni di Prosody o Jicofo in una nuova installazione senza prima consultare la guida corrispondente al vostro metodo di installazione.

Docker: consentire l'avvio delle stanze solo agli utenti autorizzati

Questa procedura presuppone che tu abbia già Jitsi Meet in esecuzione dal progetto ufficiale Docker Compose e che tu possa modificarne il .envfile. L'esempio seguente utilizza la modalità di autenticazione integrata internal. Non aggiunge una pagina di registrazione pubblica: un amministratore crea e rimuove gli account autorizzati.

1. Abilita l'autenticazione nel file di ambiente

Apri il .envfile utilizzato dalla tua distribuzione Jitsi Compose. Imposta le variabili di autenticazione in questo modo:

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

Assicurati che le righe siano impostazioni attive e non commenti che iniziano con #. Con ENABLE_GUESTS=1, le persone che non hanno effettuato l'accesso possono unirsi come ospiti dopo che un utente autenticato ha aperto la conferenza. Se desideri che ogni partecipante si autentichi, imposta ENABLE_GUESTS=0; questo modifica chi può unirsi, non solo chi può creare stanze.

La guida di Docker documenta queste variabili e il flusso di lavoro integrato per la gestione degli account. Consulta la sezione Autenticazione per Docker per l'elenco aggiornato dei tipi e delle opzioni di autenticazione supportati.

2. Applicare la configurazione

Dalla directory contenente il file Compose, applica l'ambiente aggiornato. Compose ricreerà i servizi la cui configurazione è stata modificata:

docker compose up -d

Prima di creare gli account, verifica che i container siano in esecuzione. Se utilizzi un progetto Compose personalizzato, un nome di progetto diverso o un livello di orchestrazione, esegui l'aggiornamento equivalente per tale distribuzione anziché avviare un secondo stack Jitsi.

3. Creare un account per ogni host di stanza approvato

Apri una shell nel contenitore Prosody:

docker compose exec prosody /bin/bash

Successivamente, registra un utente Jitsi sul dominio XMPP predefinito di Docker:

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

Sostituisci entrambi i segnaposto con il nome utente e una password univoca per quella persona. Non includere le parentesi angolari. Per un secondo host autorizzato, esegui nuovamente il comando con un nome utente diverso. Il comando mostrato utilizza il dominio Docker predefinito meet.jitsi; se lo hai modificato XMPP_DOMAIN, segui il dominio configurato dalla tua distribuzione. La guida Docker corrente documenta il comando del container Prosody e il relativo comando di rimozione.

Per revocare un utente, accedi al container Prosody ed esegui:

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

Limitate l'elenco degli account alle sole persone autorizzate ad avviare conferenze. Il nome della stanza non costituisce un meccanismo di controllo degli accessi e l'accesso all'account dovrebbe essere revocato quando l'organizzatore non ne ha più bisogno.

4. Testare separatamente i percorsi host e guest

Utilizza una finestra di navigazione in incognito o un profilo browser separato, in modo che una sessione di accesso Jitsi esistente non nasconda il risultato. Apri l'URL pubblico di Jitsi e prova ad avviare una nuova stanza senza autenticarti. L'istanza dovrebbe richiedere l'autenticazione prima di assegnare la nuova conferenza. Accedi con uno degli account che hai creato e avvia una stanza; quindi verifica che la stanza si apra.

Successivamente, apri il link della stanza in una sessione del browser separata, senza autenticazione. Con l'accesso ospite abilitato, l'ospite dovrebbe essere in grado di partecipare alla conferenza dopo che l'host autenticato l'ha avviata. La guida Docker di Jitsi afferma che gli utenti non autenticati devono attendere che un utente si autentichi quando l'accesso ospite è abilitato.

Per le nuove installazioni di Debian o Ubuntu, utilizzare la guida corrente all'autenticazione tramite token.

Il manuale di self-hosting di Jitsi attualmente disponibile offre un percorso di autenticazione più recente che utilizza l'autenticazione tramite token. L'esempio documentato collega Jitsi a Keycloak, configura l'host Prosody in modo che richieda un token e aggiunge un dominio guest anonimo quando gli ospiti devono essere autorizzati. Nella configurazione di Jitsi, la configurazione documentata utilizza authentication = "token"e allow_empty_token = falseper l'host principale, quindi mappa il dominio guest come jitsi-anonymous. Segui la guida completa all'autenticazione per il realm Keycloak, gli URL di reindirizzamento del client, il routing del reverse proxy, Prosody e le impostazioni del client web di Jitsi. Sostituisci ogni hostname di esempio con il tuo e mantieni l'endpoint del provider di identità protetto da HTTPS.

L'autenticazione tramite token è utile quando gli account devono essere gestiti da un provider di identità o quando l'applicazione emette token di accesso specifici per le stanze. Richiede un emittente e una convalida del token configurati correttamente; la semplice attivazione di un'impostazione del browser non limita in modo sicuro la creazione delle stanze. Se hai bisogno di account basati su LDAP con Docker, la guida di Docker documenta anche una modalità LDAP, ma le impostazioni di connessione LDAP, certificato e filtro devono corrispondere alla tua directory.

La creazione della stanza è separata dalla privacy della stanza.

L'autenticazione risponde alla domanda "chi può avviare una conferenza?", ma da sola non risponde alla domanda "chi può accedere a questa stanza?". Se è consentito l'accesso agli ospiti, chiunque ottenga l'URL della stanza potrebbe tentare di parteciparvi. È possibile aggiungere una password per la stanza o configurare la sala d'attesa per le riunioni che ammettono solo i partecipanti invitati. La guida di Jitsi per l'hosting autonomo distingue la possibilità di avviare conferenze a livello di server dai controlli di accesso gestiti nella singola stanza.

Problemi comuni da verificare

• La creazione delle stanze funziona ancora in modo anonimo: verifica ENABLE_AUTH=1che sia attiva nel file di ambiente utilizzato dal progetto Compose in esecuzione, quindi riapplica la configurazione.
• Ogni partecipante riceve una richiesta di accesso: verifica se questa opzione ENABLE_GUESTSè disabilitata. Tale impostazione richiede l'autenticazione dei partecipanti; non è necessaria quando il tuo obiettivo è autenticare gli host con i partecipanti ospiti.
• Un nuovo account non può accedere: verifica di averlo registrato sul dominio configurato per la tua distribuzione. Il comando predefinito di Docker utilizza meet.jitsi; i domini XMPP personalizzati richiedono valori corrispondenti.
• Gli ospiti non possono accedere prima dell'host: questo è coerente con il comportamento di accesso degli ospiti. L'host autenticato deve avviare la stanza per primo, quindi chiedere agli ospiti di utilizzare il link per accedere alla stanza.
• Seguendo un tutorial relativo a un altro tipo di installazione: non mescolare percorsi di pacchetti Debian, configurazioni generate da Docker e vecchi snippet di dominio sicuro. Consulta la sezione del manuale relativa alla tua installazione e leggi le relative note di deprecazione.

Lista di controllo per la verifica

1. Un browser non autenticato non può creare una nuova stanza.
2. Un utente autorizzato può accedere e avviare una stanza.
3. Un account rimosso non può più autenticarsi.
4. L'accesso degli ospiti si comporta come previsto per le ENABLE_GUESTSimpostazioni configurate.
5. Anche per le riunioni private è previsto l'utilizzo di una password per la sala o, ove necessario, di una politica specifica per la hall.

La decisione fondamentale riguarda la scelta tra l'utilizzo di account interni creati individualmente per la propria istanza di Jitsi o di token emessi tramite un provider di identità. Per un'implementazione Docker Compose esistente, l'autenticazione interna rappresenta un metodo diretto per limitare la creazione di stanze al ristretto gruppo di utenti registrati. Per una nuova installazione, si consiglia di iniziare seguendo la guida all'autenticazione tramite token e di mantenere configurati separatamente i controlli di ammissione a livello di stanza.

Riferimenti ufficiali

• Jitsi Meet: Autenticazione (guida attuale; ultimo aggiornamento 5 ottobre 2026)
• Jitsi Meet: Guida all'hosting autonomo — Docker
• Jitsi Meet: Configurazione sicura del dominio (contrassegnato come obsoleto per le nuove installazioni)
• Jitsi Meet: Guida all'hosting autonomo — Debian/Ubuntu