Au 6 octobre 2026, le manuel d'auto-hébergement de Jitsi préconise toujours de limiter la création de salles de conférence aux seuls utilisateurs authentifiés, les invités pouvant les rejoindre ultérieurement. Cependant, il déconseille désormais l'utilisation de l'ancienne procédure « Secure Domain » pour les nouvelles installations et recommande l'authentification par jeton. La configuration appropriée dépend de votre méthode d'installation de Jitsi : ce guide décrit la procédure d'authentification interne directe pour les déploiements Docker et explique la marche à suivre pour les nouvelles installations Debian ou Ubuntu.
Ces paramètres déterminent qui peut créer une salle. Ils ne rendent pas automatiquement toutes les salles privées. Les mots de passe des salles, le hall d'accueil et le processus d'invitation sont des paramètres distincts.
| Déploiement | choix pratique | Ce qu'il contrôle |
|---|---|---|
| Déploiement officiel Docker Compose | Activez l'authentification interne et provisionnez les comptes dans Prosody. | Seuls les comptes que vous créez peuvent démarrer une conférence ; la participation des invités est configurable. |
| Nouveau déploiement Debian ou Ubuntu | Suivez le guide d'authentification par jeton de Jitsi, qui utilise Keycloak dans son exemple documenté. | Seuls les utilisateurs qui reçoivent un jeton valide de votre flux d'identité peuvent démarrer une conférence. |
| Installation existante utilisant l'ancienne configuration de domaine sécurisé | Conservez-la uniquement comme configuration héritée pendant la planification de la mise à niveau. | La distinction plus ancienne entre hôte authentifié et invité anonyme |
Le guide d'authentification Jitsi actuel décrit la création de salles authentifiées avec des invités anonymes, tandis que l' ancienne page relative aux domaines sécurisés indique clairement que cette méthode est obsolète pour les nouvelles installations. Évitez de copier d'anciens paramètres Prosody ou Jicofo dans une nouvelle installation sans consulter le guide correspondant à votre méthode d'installation.
Cette procédure suppose que vous utilisez déjà Jitsi Meet depuis le projet Docker Compose officiel et que vous pouvez modifier son .envfichier de configuration. L'exemple ci-dessous utilise le mode d'authentification intégré internal. Il ne prévoit pas de page d'inscription publique : un administrateur crée et supprime les comptes autorisés.
Ouvrez le .envfichier utilisé par votre déploiement Jitsi Compose. Configurez les variables d'authentification comme suit :
ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internalAssurez-vous que les lignes correspondent à des paramètres actifs et non à des commentaires commençant par ` #.`. Avec ` ENABLE_GUESTS=1.`, les personnes non connectées peuvent rejoindre la conférence en tant qu'invités une fois qu'un utilisateur authentifié l'a ouverte. Si vous souhaitez que chaque participant s'authentifie, définissez `.`ENABLE_GUESTS=0 ; cela modifie les personnes autorisées à rejoindre la conférence, et pas seulement celles autorisées à créer des salles.
Le guide Docker documente ces variables et le flux de travail intégré pour les comptes. Consultez la section Authentification du guide Docker pour obtenir la liste actuelle des types et options d'authentification pris en charge.
Depuis le répertoire contenant votre fichier Compose, appliquez l'environnement mis à jour. Compose recréera les services dont la configuration a été modifiée :
docker compose up -dVérifiez que les conteneurs sont en cours d'exécution avant de créer des comptes. Si vous utilisez un projet Compose personnalisé, un nom de projet différent ou une couche d'orchestration, effectuez la mise à jour correspondante pour ce déploiement plutôt que de démarrer une seconde pile Jitsi.
Ouvrez un shell dans le conteneur Prosody :
docker compose exec prosody /bin/bashEnsuite, enregistrez un utilisateur Jitsi sur le domaine XMPP Docker par défaut :
prosodyctl --config /run/prosody/config/prosody.cfg.lua register <username> meet.jitsi <strong-password>Remplacez les deux espaces réservés par le nom d'utilisateur et un mot de passe unique pour cette personne. N'incluez pas les chevrons. Pour un deuxième hôte autorisé, exécutez à nouveau la commande avec un nom d'utilisateur différent. La commande affichée utilise le domaine Docker par défautmeet.jitsi ; si vous l'avez modifié XMPP_DOMAIN, utilisez le domaine configuré par votre déploiement. Le guide Docker actuel documente la commande du conteneur Prosody et la commande de suppression associée.
Pour révoquer un utilisateur, accédez au conteneur Prosody et exécutez :
prosodyctl --config /run/prosody/config/prosody.cfg.lua unregister <username> meet.jitsiLimitez la liste des comptes aux personnes autorisées à créer des conférences. Le nom d'une salle ne constitue pas un mécanisme de contrôle d'accès ; l'accès à un compte doit être supprimé dès que l'organisateur n'en a plus besoin.
Utilisez une fenêtre de navigation privée ou un profil de navigateur distinct afin qu'une session Jitsi existante n'interfère pas avec le résultat. Ouvrez l'URL publique de Jitsi et essayez de créer une nouvelle salle sans vous authentifier. L'instance devrait exiger une authentification avant d'attribuer la nouvelle conférence. Connectez-vous avec l'un des comptes que vous avez créés et créez une salle ; vérifiez ensuite que la salle s'ouvre.
Ensuite, ouvrez le lien de la salle dans une session de navigateur distincte et non authentifiée. L'accès invité étant activé, l'invité pourra rejoindre la conférence une fois que l'hôte authentifié l'aura démarrée. Le guide Docker de Jitsi précise que les utilisateurs non authentifiés doivent attendre qu'un utilisateur s'authentifie lorsque l'accès invité est activé.
Le manuel d'auto-hébergement actuel de Jitsi propose une méthode d'authentification plus récente utilisant l'authentification par jeton. Son exemple documenté connecte Jitsi à Keycloak, configure l'hôte Prosody pour exiger un jeton et ajoute un domaine invité anonyme lorsque les invités doivent être autorisés. Dans la configuration Jitsi, la configuration documentée utilise `<nom_hôte>` authentication = "token"et `< allow_empty_token = falsenom_hôte>` pour l'hôte principal, puis mappe le domaine invité comme ` <nom_domaine>`. Suivez le guide d'authentificationjitsi-anonymous complet pour le domaine Keycloak, les URL de redirection client, le routage du proxy inverse, Prosody et les paramètres du client web Jitsi. Remplacez chaque nom d'hôte d'exemple par le vôtre et assurez-vous que le point de terminaison du fournisseur d'identité est protégé par HTTPS.
L'authentification par jeton est utile lorsque les comptes doivent être gérés par un fournisseur d'identité ou lorsque votre application émet des jetons d'accès spécifiques à une salle. Elle nécessite un émetteur et une validation des jetons correctement configurés ; activer une option dans un paramètre du navigateur ne suffit pas à sécuriser la création de salles. Si vous avez besoin de comptes LDAP avec Docker, le guide Docker décrit également un mode LDAP, mais la connexion LDAP, le certificat et les paramètres de filtrage doivent correspondre à votre annuaire.
L'authentification répond à la question « Qui peut démarrer une conférence ? ». Elle ne répond pas à elle seule à la question « Qui peut accéder à cette salle ? ». Si les invités sont autorisés, toute personne ayant accès à l'URL de la salle peut tenter de la rejoindre. Il est donc recommandé d'ajouter un mot de passe ou de configurer la salle d'attente pour les réunions réservées aux participants invités. Le guide d'auto-hébergement de Jitsi distingue la possibilité, au niveau du serveur, de démarrer des conférences des contrôles d'accès gérés dans chaque salle.
ENABLE_AUTH=1est bien activée dans le fichier d’environnement utilisé par le projet Compose en cours d’exécution, puis réappliquez la configuration.ENABLE_GUESTSl’authentification est désactivée. Ce paramètre exige l’authentification des participants ; il est inutile lorsque votre objectif est d’avoir des hôtes authentifiés avec des participants invités.meet.jitsi ; les domaines XMPP personnalisés nécessitent des valeurs correspondantes.ENABLE_GUESTSparamètres.La décision cruciale consiste à choisir entre l'utilisation de comptes internes provisionnés individuellement ou de jetons émis par un fournisseur d'identité pour votre instance Jitsi. Pour un déploiement Docker Compose existant, l'authentification interne permet de limiter la création de salles aux seuls utilisateurs enregistrés. Pour une nouvelle installation, suivez le guide d'authentification par jeton et configurez séparément les contrôles d'accès au niveau des salles.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
