Comment activer l'authentification et la protection par mot de passe dans Jitsi Meet

Jitsi Meet dispose de deux mécanismes de protection distincts : l’authentification du serveur détermine qui peut créer une réunion, tandis que le mot de passe de la salle empêche les personnes ne le connaissant pas de la rejoindre. Ces mécanismes répondent à des problématiques différentes. Sur un serveur auto-hébergé, l’ancienne configuration de « domaine sécurisé » de Prosody permet d’exiger un nom d’utilisateur et un mot de passe pour créer des salles, tout en autorisant les invités. La documentation actuelle de Jitsi indique que cette méthode est obsolète pour les nouvelles installations et recommande l’authentification par jeton. Les administrateurs existants peuvent utiliser la procédure ci-dessous comme guide de compatibilité, mais doivent planifier les nouveaux déploiements en utilisant une configuration de jeton ou de fournisseur d’identité prise en charge.

Les mots de passe de salle sont une fonctionnalité distincte, utilisable pendant la réunion, et restent utiles en complément de l'authentification serveur. Définissez un mot de passe après le démarrage de la salle, partagez-le via un canal privé et testez la procédure de connexion depuis un autre navigateur avant d'inviter des participants.

De quel type de protection avez-vous besoin ?

Pour une petite réunion, un nom de salle unique et un mot de passe peuvent suffire. Pour une organisation exigeant la création de salles par compte, configurez également l'authentification du serveur. Pour les nouveaux déploiements auto-hébergés, consultez le guide d'authentification Jitsi et la configuration d'authentification par jeton correspondante avant de choisir une solution.

Comment protéger une salle Jitsi par un mot de passe ?

Démarrez la réunion, ouvrez le menu Sécurité ou Options de réunion dans la barre d'outils, sélectionnez l'option Mot de passe et saisissez un mot de passe de salle robuste. L'intitulé et l'icône du menu peuvent varier selon la version du client. Si la réunion est déjà en cours, la définition d'un mot de passe n'affectera pas les participants ultérieurs ; les personnes déjà connectées ne seront pas automatiquement exclues. Envoyez le mot de passe séparément du lien de réunion lorsque la confidentialité est importante.

La FAQ de Jitsi explique que le mot de passe d'une salle est supprimé à la fin de la réunion. Par conséquent, il ne faut pas supposer que les réunions récurrentes le conservent. Il est recommandé de le redéfinir pour chaque nouvelle réunion et de vérifier ce comportement dans votre environnement. Toute personne recevant ou se voyant transférer le mot de passe peut potentiellement accéder à la salle ; un mot de passe est donc différent d'une liste d'utilisateurs autorisés. Consultez la FAQ officielle de Jitsi relative à la protection des réunions .

Qu’est-ce que l’authentification du serveur change ?

Dans l'architecture classique de « domaine sécurisé », Prosody authentifie les créateurs de salles via des comptes locaux. Jitsi permet ensuite aux participants non authentifiés de se connecter via un domaine invité. Cette solution est utile lorsque seuls les membres du personnel doivent créer des salles et que les participants n'ont pas besoin de compte. Elle n'oblige pas chaque participant à se connecter. Si l'authentification de chaque utilisateur est requise, l'accès invité doit être désactivé ou remplacé par la politique d'identité et d'accès de votre système d'authentification actuel.

La documentation de Jitsi indique que cette ancienne méthode de domaine sécurisé est obsolète pour les nouvelles installations. Ne poursuivez que si vous comprenez cette limitation et que vous gérez un serveur existant compatible. Avant toute modification, identifiez le mode d'installation de Jitsi, notez le nom d'hôte de Jitsi Meet, sauvegardez les fichiers de configuration Prosody, Jicofo et web, et maintenez une session d'administration ou une console active en cas d'interruption de service due à une erreur de syntaxe.

Comment activer la configuration de domaine sécurisé héritée lors de l'installation d'un paquet Debian ou Ubuntu ?

1. Modifier les hôtes virtuels de Prosody

Ouvrez le fichier Prosody correspondant à votre nom d'hôte Jitsi /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. Remplacez le nom d'hôte d'exemple ci-dessous par votre domaine réel. Dans l'hôte virtuel principal, modifiez le mode d'authentification pour utiliser le hachage des mots de passe internes. Ajoutez ensuite l'hôte virtuel invité.

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

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

Conservez les autres options et modules existants. Ne créez pas d'enregistrements DNS ni de certificat public pour ce domaineguest.jitsi.example.com ; dans cette configuration, il s'agit d'un domaine interne à Jitsi.

2. Informez le client Web du domaine invité

Ouvrez l'objet existant /etc/jitsi/meet/jitsi.example.com-config.jset ajoutez- y le contenu . Conservez les entrées existantes et les autres, et vérifiez attentivement les virgules :anonymousdomainhostsdomain

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

3. Activez l'authentification dans Jicofo

Modifier /etc/jitsi/jicofo/jicofo.conf. Ajoutez les paramètres d'authentification à l'intérieur du jicofobloc existant ; ne créez pas de bloc de niveau supérieur dupliqué :

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

Si le fichier comporte déjà une jicofosection, fusionnez-y ces propriétés. La syntaxe de configuration et les fichiers générés peuvent varier selon la version du package ; comparez donc le résultat avec la page du manuel correspondant à votre installation avant de redémarrer les services.

4. Redémarrez les services et créez un compte

Après avoir vérifié les modifications, redémarrez les services en tant qu'administrateur :

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

Créez un compte de créateur de salle sur Prosody. Remplacez les espaces réservés ; n’utilisez jamais l’exemple de domaine ni un mot de passe faible sur un serveur en production.

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

Chaque compte est associé au nom d'hôte Jitsi. Il est recommandé de créer des comptes individuels plutôt que de partager un seul identifiant d'administrateur si vous devez révoquer l'accès ultérieurement. La documentation relative aux domaines sécurisés de Jitsi répertorie les chemins de configuration spécifiques au package et la commande d'enregistrement. Elle indique également explicitement que cette méthode est obsolète.

En quoi la configuration diffère-t-elle dans Docker ?

Ne modifiez pas les fichiers à l'intérieur des conteneurs en cours d'exécution et ne copiez pas les chemins des paquets Debian dans un déploiement Docker. Dans la configuration officielle de Docker Compose, l'authentification est gérée par le fichier d'environnement du déploiement. Le manuel documente les valeurs pertinentes pour l'authentification des comptes internes :

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

Laissez l'accès invité activé si les participants doivent pouvoir se connecter sans créer de compte. Avec l'accès invité activé, les utilisateurs non authentifiés peuvent se connecter selon le comportement configuré ; ils ne deviennent pas créateurs de salle authentifiés. Appliquez les modifications d'environnement à l'aide du workflow Compose pour votre déploiement et consultez les journaux si les services ne démarrent pas correctement.

Créez un utilisateur interne via le service Prosody plutôt que de modifier la configuration générée du conteneur. Le manuel officiel explique comment ouvrir un shell dans le conteneur Prosody et enregistrer un utilisateur prosodyctl. Le chemin de configuration et le domaine XMPP dépendent de la version de Compose ; dans l'image Docker documentée, la configuration Prosody se trouve sous `/etc/prosody/prosody` /config/prosody.cfg.lua, et le domaine XMPP d'exemple est `/etc/ prosody meet.jitsi/prosody`. Utilisez la commande et les valeurs exactes documentées pour votre version. Consultez le guide d'auto-hébergement Docker officiel pour plus d'informations sur les variables d'environnement, la création de compte et le comportement de la configuration générée.

Comment pouvez-vous vérifier que la protection fonctionne ?

• Ouvrez une fenêtre de navigation privée et essayez de créer une nouvelle salle. La configuration classique devrait vous demander vos identifiants de compte.
• Connectez-vous avec le nouveau compte et créez une salle. Vérifiez que la réunion se charge correctement et que l'hôte dispose des commandes de modération attendues.
• Depuis un autre navigateur, connectez-vous en tant qu'invité. Si l'option « invités » est activée, la connexion devrait fonctionner sans compte créateur ; ajoutez le mot de passe de la salle ou le lobby si une vérification d'accès supplémentaire est nécessaire.
• Définissez un mot de passe pour la salle, puis essayez de vous y connecter depuis une nouvelle fenêtre de navigation privée, avec et sans ce mot de passe. Vérifiez qu'un participant déjà présent reste connecté même lorsque le mot de passe est défini.
• Après avoir terminé la réunion test, ouvrez une nouvelle salle et vérifiez si le mot de passe doit être redéfini, comme indiqué dans la FAQ de Jitsi.

Si l'invite de connexion n'apparaît jamais, vérifiez les noms d'hôtes Prosody, le bloc Jicofo, anonymousdomainla valeur du client et les journaux de service. Une erreur de configuration fréquente consiste à utiliser un domaine invité qui ne correspond pas entre Prosody et le serveur config.js, ou à ajouter un second bloc Jicofo au lieu d'étendre le bloc existant. Si les invités ne peuvent pas se connecter, vérifiez que l'accès invité a bien été activé et que le domaine invité configuré correspond au nom d'hôte principal.

Que choisir pour une nouvelle installation ?

N'utilisez pas la méthode de domaine sécurisé obsolète pour un nouveau déploiement, sauf raison de compatibilité spécifique. La documentation Jitsi actuelle sur l'auto-hébergement recommande l'authentification par jeton pour les nouvelles installations, tandis que son guide d'authentification plus complet décrit l'intégration de fournisseurs d'identité plus récents. Ces approches nécessitent une configuration supplémentaire de l'émetteur, de la signature ou du fournisseur d'identité ; elles ne sont pas interchangeables avec un mot de passe de salle Prosody. Choisissez le modèle qui correspond à vos besoins, puis utilisez des mots de passe de salle ou un hall d'accueil comme contrôles distincts au niveau des réunions, le cas échéant.

En résumé : utilisez l’authentification par compte ou jeton pour contrôler qui peut créer des salons, et définissez un mot de passe pour limiter l’accès ultérieur aux personnes qui le connaissent. Testez les deux méthodes indépendamment, car l’activation de l’une n’active pas automatiquement l’autre.

Références officielles

• Jitsi Meet : Authentification
• Jitsi Meet : Configuration sécurisée du domaine (obsolète)
• Jitsi Meet : Authentification par jeton
• Guide d'auto-hébergement Docker pour Jitsi Meet
• Jitsi Meet : FAQ et protection des réunions