Come abilitare l'autenticazione e la protezione tramite password in Jitsi Meet

Jitsi Meet offre due controlli di protezione distinti: l'autenticazione del server determina chi può creare una riunione, mentre la password della stanza impedisce l'accesso a chi non la conosce. Questi due sistemi risolvono problemi diversi. Su un server self-hosted, la vecchia configurazione "dominio sicuro" di Prosody poteva richiedere nome utente e password per creare le stanze, consentendo comunque agli ospiti di partecipare. Il manuale di Jitsi ora indica questo metodo come obsoleto per le nuove installazioni e raccomanda invece l'autenticazione basata su token. Gli amministratori esistenti possono utilizzare la procedura seguente come guida alla compatibilità, ma dovrebbero pianificare le nuove implementazioni in base a una configurazione di token o di provider di identità supportata.

Le password per le stanze sono una funzionalità separata, integrata nella riunione, e rimangono utili insieme all'autenticazione del server. Imposta una password dopo l'avvio della stanza, condividila tramite un canale privato e testa la procedura di accesso da un secondo browser prima di invitare i partecipanti.

Di che tipo di protezione hai bisogno?

Per una riunione di piccole dimensioni, un nome univoco per la stanza e una password potrebbero essere sufficienti. Per un'organizzazione che necessita della creazione di stanze basate su account, è necessario configurare anche l'autenticazione del server. Per le nuove implementazioni self-hosted, si consiglia di consultare la guida all'autenticazione di Jitsi e la relativa configurazione dell'autenticazione tramite token prima di scegliere un'implementazione.

Come si protegge con password una stanza Jitsi?

Avvia la riunione, apri il menu "Sicurezza" o "Opzioni riunione" nella barra degli strumenti, scegli l'azione "Password" e inserisci una password sicura per la sala riunioni. L'etichetta e l'icona del menu possono variare a seconda della versione del client. Se la riunione è già in corso, l'impostazione di una password influirà sui successivi accessi; le persone già entrate non verranno rimosse automaticamente. Invia la password separatamente dal link della riunione quando la riservatezza è importante.

Le FAQ di Jitsi spiegano che la password di una sala riunioni viene rimossa al termine della riunione stessa, quindi non bisogna dare per scontato che le riunioni ricorrenti la conservino. Impostatela nuovamente per ogni nuova riunione e verificate il comportamento nel vostro ambiente. Chiunque riceva o venga inoltrato alla password potrebbe essere in grado di accedere, quindi una password non è la stessa cosa di un elenco di accesso per utenti nominativi. Consultate le FAQ ufficiali di Jitsi sulla protezione delle riunioni .

Che cosa cambia con l'autenticazione del server?

Nella classica architettura a "dominio sicuro", Prosody autentica i creatori di stanze tramite account locali. Jitsi consente quindi ai partecipanti non autenticati di connettersi attraverso un dominio guest. Questa soluzione è utile quando solo lo staff deve creare stanze, ma i partecipanti non necessitano di un account. In questo modo, non è necessario che ogni partecipante effettui l'accesso. Se ogni utente deve autenticarsi, l'accesso guest deve essere disabilitato o sostituito dalla policy di identità e accesso utilizzata dal sistema di autenticazione attualmente in uso.

La documentazione di Jitsi etichetta questo vecchio metodo di dominio sicuro come obsoleto per le nuove installazioni. Procedere solo se si comprende tale limitazione e si sta gestendo un server esistente compatibile. Prima di apportare modifiche, identificare la modalità di installazione di Jitsi, annotare il nome host di Jitsi Meet, eseguire il backup dei file di configurazione di Prosody, Jicofo e Web e mantenere una sessione o una console di amministrazione attiva nel caso in cui un errore di sintassi interrompa il servizio.

Come si abilita la configurazione legacy del dominio sicuro durante l'installazione di un pacchetto Debian o Ubuntu?

1. Modifica gli host virtuali di Prosody

Apri il file Prosody per il tuo hostname Jitsi, normalmente /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. Sostituisci l'hostname di esempio qui sotto con il dominio reale. Nell'host virtuale principale, cambia la modalità di autenticazione in password interne con hashing. Aggiungi l'host virtuale guest dopo di esso:

VirtualHost "jitsi.example.com"
    authentication = "internal_hashed"

VirtualHost "guest.jitsi.example.com"
    authentication = "jitsi-anonymous"
    c2s_require_encryption = false

Mantieni le altre opzioni e i moduli esistenti. Non creare record DNS o un certificato pubblico per guest.jitsi.example.com; in questa configurazione è un dominio interno di Jitsi.

2. Informa il client web sul dominio guest

Apri /etc/jitsi/meet/jitsi.example.com-config.jse aggiungi anonymousdomainall'interno hostsdell'oggetto esistente. Mantieni le domainvoci esistenti e le altre, e controlla attentamente le virgole:

hosts: {
    domain: 'jitsi.example.com',
    anonymousdomain: 'guest.jitsi.example.com'
},

3. Abilita l'autenticazione in Jicofo

Modifica /etc/jitsi/jicofo/jicofo.conf. Aggiungi le impostazioni di autenticazione all'interno del blocco esistente jicofo; non creare un blocco di primo livello duplicato:

jicofo {
  authentication {
    enabled = true
    type = XMPP
    login-url = "jitsi.example.com"
  }
}

Se il file contiene già una jicofosezione apposita, unisci queste proprietà al suo interno. La sintassi di configurazione e i file generati possono variare a seconda della versione del pacchetto, quindi confronta il risultato con la pagina del manuale corrente relativa alla tua installazione prima di riavviare i servizi.

4. Riavvia i servizi e crea un account

Dopo aver verificato le modifiche, riavvia i servizi come amministratore:

sudo systemctl restart prosody
sudo systemctl restart jicofo
sudo systemctl restart jitsi-videobridge2

Registra un account per la creazione di stanze su Prosody. Sostituisci i segnaposto; non utilizzare mai il dominio di esempio o una password debole su un server di produzione:

sudo prosodyctl register <username> jitsi.example.com <strong-password>

Ogni account è associato al nome host di Jitsi. Crea account individuali anziché condividere un'unica credenziale di amministratore, qualora dovessi revocare l'accesso in seguito. La documentazione di Jitsi relativa ai domini sicuri elenca i percorsi di configurazione specifici del pacchetto e il comando di registrazione. Indica inoltre esplicitamente che tale metodo è obsoleto.

In che modo la configurazione differisce in Docker?

Non modificare i file all'interno dei container in esecuzione né copiare i percorsi dei pacchetti Debian in un deployment Docker. Nella configurazione ufficiale di Docker Compose, l'autenticazione viene configurata tramite il file di ambiente del deployment. Il manuale documenta i seguenti valori rilevanti per l'autenticazione degli account interni:

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

Mantieni l'accesso ospiti abilitato se i partecipanti devono poter accedere senza un proprio account. Con l'accesso ospiti abilitato, gli utenti non autenticati possono accedere in base al comportamento configurato per gli ospiti; non diventano creatori di stanze autenticati. Applica le modifiche all'ambiente utilizzando il flusso di lavoro Compose per la tua distribuzione e controlla i log se i servizi non si avviano correttamente.

Crea un utente interno tramite il servizio Prosody anziché modificare la configurazione del container generato. Il manuale ufficiale mostra come aprire una shell nel container Prosody e registrare un utente con prosodyctl. Il percorso di configurazione e il dominio XMPP dipendono dalla versione di Compose; nell'immagine Docker documentata, la configurazione di Prosody si trova in /config/prosody.cfg.lua, e il dominio XMPP di esempio è meet.jitsi. Utilizza esattamente il comando e i valori documentati per la versione che stai utilizzando. Consulta la guida ufficiale all'hosting self-service di Docker per informazioni su variabili d'ambiente, creazione di account e comportamento della configurazione generata.

Come si può verificare che la protezione funzioni?

• Apri una finestra di navigazione in incognito e prova a creare una nuova stanza. La configurazione classica dovrebbe richiedere le credenziali dell'account.
• Accedi con il nuovo account e crea una stanza. Verifica che la riunione si carichi correttamente e che l'organizzatore disponga dei controlli di moderazione previsti.
• Da un altro browser, accedi come ospite. Se l'opzione per gli ospiti è abilitata, l'accesso dovrebbe funzionare anche senza un account creatore; aggiungi la password della stanza o la lobby quando è necessario un ulteriore controllo di accesso.
• Imposta una password per la stanza, quindi prova a connetterti da una nuova finestra privata sia senza password che con la password impostata. Verifica che un partecipante già presente rimanga connesso anche quando viene impostata la password.
• Dopo aver terminato la riunione di prova, avvia una nuova stanza e verifica se è necessario impostare nuovamente la password, come descritto nelle FAQ di Jitsi.

Se la richiesta di accesso non viene visualizzata, controllare i nomi host di Prosody, il blocco Jicofo, anonymousdomainil valore client e i log di servizio. Un errore di configurazione comune è l'utilizzo di un dominio guest non corrispondente tra Prosody e config.js, oppure l'aggiunta di un secondo blocco Jicofo invece di estendere quello esistente. Se gli ospiti non riescono ad accedere, verificare che l'accesso guest sia stato abilitato intenzionalmente e che il dominio guest configurato corrisponda al nome host principale.

Cosa dovresti scegliere per una nuova installazione?

Non iniziare una nuova implementazione con la ricetta deprecata del dominio sicuro a meno che non ci siano motivi specifici di compatibilità. La documentazione attuale di Jitsi sull'hosting autonomo raccomanda l'autenticazione tramite token per le nuove installazioni, mentre la guida all'autenticazione più ampia documenta l'integrazione con i provider di identità più recenti. Questi approcci richiedono una configurazione aggiuntiva per l'emittente, la firma o il provider di identità; non sono intercambiabili con una password per la sala riunioni di Prosody. Scegli il modello più adatto alle tue esigenze, quindi utilizza le password per le sale riunioni o una lobby come controlli separati a livello di riunione, ove appropriato.

In breve: utilizzate l'autenticazione tramite account o token per controllare chi può creare stanze e impostate una password per la stanza per limitare gli accessi successivi solo a chi conosce la password. Testate entrambe le opzioni separatamente, perché l'attivazione di una non abilita automaticamente l'altra.

Riferimenti ufficiali

• Jitsi Meet: Autenticazione
• Jitsi Meet: Configurazione sicura del dominio (obsoleto)
• Jitsi Meet: Autenticazione tramite token
• Jitsi Meet: Guida all'hosting autonomo con Docker
• Jitsi Meet: domande frequenti e protezione delle riunioni