Autoriser les utilisateurs approuvés à créer des salles Jitsi avec connexion Keycloak

Pour limiter la création de salles Jitsi Meet à certaines personnes, exigez une authentification de l'hôte et n'émettez des identifiants qu'aux comptes approuvés. Pour les nouvelles installations auto-hébergées, Jitsi recommande désormais l'authentification par jeton ; ce guide utilise Keycloak comme fournisseur d'identité et autorise les invités à rejoindre les salles uniquement après leur création par un hôte approuvé.

1. Vérifiez le déploiement et choisissez vos comptes hôtes

Ces instructions concernent une installation Jitsi Meet auto-hébergée à partir de paquets Debian ou Ubuntu, avec un accès administrateur à Prosody, Nginx et à la configuration web de Jitsi. Elles supposent que Keycloak est déjà installé ou peut être déployé de manière sécurisée. Prosody est le serveur de messagerie XMPP ; un jeton web JSON (JWT) est une authentification signée permettant de prouver l’authentification d’un utilisateur. Keycloak est un fournisseur d’identité qui gère la connexion des utilisateurs.

Le manuel Jitsi indique que l'ancienne méthode d'authentification par nom d'utilisateur et mot de passe pour le domaine sécurisé est obsolète et recommande l'authentification par jeton pour les nouvelles installations. Ses instructions d'authentification actuelles ont été mises à jour le 5 octobre 2026. Si vous utilisez déjà Docker, ne copiez pas les chemins d'accès aux paquets ci-dessous : le guide de configuration officiel de Docker utilise des variables d'environnement telles que `<configuration> ENABLE_AUTH`, ENABLE_GUESTS`<configuration>` et `<paramètre> AUTH_TYPE`.

Avant toute modification, notez le nom d'hôte de votre réunion publique, vérifiez que le protocole HTTPS fonctionne, sauvegardez les fichiers de configuration que vous prévoyez de modifier et déterminez quels comptes nommés sont autorisés à héberger des réunions. Dans cet exemple, l'adresse de la réunion estjitsi.example.com ; remplacez-la partout par votre nom d'hôte réel.

2. N'accordez l'accès à Keycloak qu'aux hôtes approuvés.

Créer un domaine dédié

Dans la console d'administration Keycloak, créez et sélectionnez un domaine nommé « domain » jitsi-realm. Un domaine est un ensemble isolé d'utilisateurs et de paramètres d'application. Désactivez l'inscription ouverte des utilisateurs et empêchez l'importation automatique d'un annuaire d'entreprise non restreint : avec cette configuration, tout compte authentifié auprès du domaine accepté peut devenir créateur de réunions.

Enregistrez le client web Jitsi

Créez un client OpenID Connect nommé jitsi. OpenID Connect (OIDC) est le protocole d'authentification utilisé par Keycloak pour renvoyer les informations d'identité à Jitsi. En suivant l'exemple officiel de Jitsi, saisissez les valeurs de rappel exactes, en adaptant le nom d'hôte :

• URI de redirection valide :https://jitsi.example.com/static/sso.html
• URI de redirection valide après déconnexion :https://jitsi.example.com/static/logout.html
• Origine Web :https://jitsi.example.com

Ajouter les personnes autorisées

Dans la section Utilisateurs, créez un compte pour chaque hôte autorisé, puis définissez le mot de passe de cet utilisateur dans la section Informations d'identification. Utilisez des comptes distincts plutôt que de partager un seul identifiant d'administrateur. Un compte qui ne doit plus créer de réunions doit être désactivé ou son authentification à ce domaine doit lui être refusée. Si vous souhaitez restreindre l'accès à un seul groupe au sein d'un domaine partagé, ajoutez une stratégie d'autorisation vérifiée séparément ; les étapes décrites ici n'appliquent pas automatiquement l'appartenance à un groupe Keycloak.

3. Connectez Keycloak au serveur Jitsi

Proxy des points de terminaison du domaine Keycloak via HTTPS

Configurez Keycloak avec le nom d'hôte public correct et les en-têtes de proxy inverse de confiance, puis acheminez /realms/les requêtes de votre nom d'hôte Jitsi vers son écouteur Keycloak privé. Pour une instance Keycloak disponible à l'adresse 127.0.0.1:18080, ajoutez le bloc location suivant dans le bloc serveur HTTPS Nginx Jitsi existant, avant les routes Jitsi générales :

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;
}

Ceci suppose que Keycloak est accessible localement sur ce port ; remplacez le port d'amont par celui de votre déploiement. N'exposez pas inutilement la console d'administration ni le port backend de Keycloak. Consultez la documentation relative au proxy inverse de Keycloak pour la configuration du proxy en production et le contrôle du nom d'hôte.

Exiger des jetons dans la prosodie

Modifiez /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. Ajoutez les paramètres de l'émetteur et du public, puis mettez à jour le bloc principal existant VirtualHostpour utiliser l'authentification par jeton. Fusionnez ces lignes avec ses autres paramètres ; ne créez pas une deuxième copie de ce bloc hôte.

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"

Pour l'accès invité, ajoutez un guest.jitsi.example.comhôte virtuel distinct avec les modules `<nom_hôte>`, `<nom_hôte>` et `<nom_module>`, comme indiqué dans les instructions Jitsi. Il s'agit d'un domaine XMPP interne : ne créez pas de DNS public ni de certificat distinct. Dans la liste des modules de l'hôte principal existant, ajoutez `<nom_module>`authentication = "jitsi-anonymous" ; c2s_require_encryption = falsedans la liste des modules du composant MUC existant , ajoutez `<nom_module>`. Un MUC est le composant de chat multi-utilisateurs qui gère les salles de conférence. Conservez les modules déjà listés.smackspersistent_lobbyconference.jitsi.example.commuc_wait_for_host

Configurer le flux de connexion du navigateur

Ajoutez à l'objet existant /etc/jitsi/meet/jitsi.example.com-config.jsles paramètres OIDC documentés par Jitsi :anonymousdomain: 'guest.jitsi.example.com'hosts

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" };

Ces valeurs mettent en œuvre le flux d'authentification par code avec PKCE (Proof Key for Code Exchange), une protection pour l'autorisation basée sur le navigateur. Le manuel Jitsi indique explicitement de désactiver jicofo.confl'authentification en mode jeton ; ne copiez pas son bloc d'authentification XMPP Secure Domain obsolète.

Validez et rechargez les services

Vérifiez la syntaxe Nginx, puis redémarrez uniquement les services mentionnés dans les instructions d'authentification par jeton. Si votre serveur Jitsi est déjà en service, effectuez ces modifications pendant une fenêtre de maintenance.

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

4. Évitez ces erreurs d'autorisation et de connexion

• Tout le monde peut toujours créer une salle : vérifiez que l’hôte principal de Prosody est authentifié par jeton, que les jetons vides sont interdits et que l’hôte invité est distinct. Testez dans une session de navigateur vierge, et non dans une session où une connexion valide est encore active.
• Les utilisateurs autorisés ne peuvent pas se connecter : comparez l’émetteur du domaine Keycloak, le nom d’hôte HTTPS public, l’ID client, l’URI de redirection et la Prosody cache_keys_url. Une redirection du navigateur ayant échoué ne prouve pas que les autorisations de l’utilisateur sont correctes.
• Les invités n'entrent jamais dans une chambre : vérifiez le domaine anonyme dans Prosody et Jitsi config.js, ainsi que les modules d'attente de l'hôte. L'état d'attente dans le hall ou chez un invité est différent d'un échec d'authentification.

5. Vérifier qui peut créer une nouvelle réunion

Ouvrez l'URL d'une salle inédite dans une fenêtre de navigation privée sans vous connecter. L'invité ne devrait pas pouvoir démarrer la conférence en tant qu'organisateur. Ensuite, connectez-vous avec un compte Keycloak autorisé et créez cette salle ; un invité pourra alors la rejoindre si vous avez activé le domaine invité. Enfin, essayez avec un compte désactivé ou non autorisé et vérifiez qu'il ne peut ni s'authentifier ni créer de nouvelle salle.

En cas d'échec d'un test, examinez sudo journalctl -u prosody -u nginx --since "10 minutes ago"les événements d'authentification Keycloak, sans publier les jetons ni les mots de passe des journaux. La correction est confirmée uniquement lorsqu'un compte autorisé peut créer une nouvelle salle et qu'un utilisateur non authentifié ne le peut pas.