Comment restreindre l'inscription des utilisateurs sur un serveur Matrix auto-hébergé

Sur un serveur Matrix auto-hébergé, « restreindre l'inscription » peut signifier différentes choses, allant de l'interdiction totale des inscriptions publiques à l'autorisation uniquement des personnes disposant d'un code d'invitation. Pour Synapse, l'option la plus simple consiste à désactiver l'inscription publique. Si vous souhaitez que de nouveaux utilisateurs puissent s'inscrire, exigez des jetons d'inscription et attribuez à chaque personne un jeton limité et expirant. Ces contrôles affectent la création de nouveaux comptes locaux ; ils ne suppriment pas les utilisateurs existants et ne désactivent pas la fédération Matrix.

Choisissez le contrôle qui convient à votre serveur

Les exemples ci-dessous concernent Synapse. Dendrite, Conduit et les autres serveurs domestiques utilisent des interfaces de configuration et d'administration différentes. Consultez la documentation de votre serveur avant d'appliquer les paramètres Synapse.

Option 1 : Désactiver l’inscription publique

Pour un serveur domestique privé, une petite organisation ou un serveur où un administrateur configure chaque compte, désactivez l'enregistrement des clients dans la configuration Synapse active :

enable_registration: false

Synapse indique que ce paramètre est désactivé par défaut. Modifiez le fichier de configuration chargé par votre service ou conteneur, validez le code YAML, puis redémarrez Synapse selon votre procédure habituelle de gestion des services. Un déploiement Docker peut monter la configuration depuis un chemin hôte ; par conséquent, la modification d'un fichier portant un nom similaire à l'intérieur du conteneur peut ne pas affecter le fichier utilisé au démarrage.

Lorsque l'enregistrement est désactivé, les utilisateurs ne peuvent pas créer de nouveaux comptes via la procédure d'inscription client classique. Les administrateurs peuvent toujours créer des comptes par les méthodes d'administration prises en charge. Synapse avertit explicitement que ce paramètre registration_shared_secretautorise la création de comptes à l'aide de ce secret, même s'il enable_registrationest désactivé. Considérez-le comme une information d'identification critique : ne le stockez pas dans les dépôts, les discussions instantanées ni les sauvegardes publiques de l'environnement ; limitez son accès ; et ne le conservez que si votre flux de travail d'administration l'exige. Toute personne connaissant ce secret peut créer des comptes, y compris des comptes d'administrateur.

Si vous utilisez OIDC, CAS ou une autre intégration SSO, vérifiez également les paramètres d'enregistrement automatique de ce fournisseur. Synapse documente les options d'enregistrement au niveau du fournisseur, car un utilisateur pourrait sinon être créé automatiquement lors de sa première connexion SSO réussie. Pour OIDC, vérifiez oidc_providers[].enable_registrationégalement les paramètres d'enregistrement généraux.

Option 2 : Autoriser l’inscription uniquement avec des jetons

Utilisez des jetons d'inscription lorsque les membres doivent pouvoir créer leur propre compte, mais que les inscriptions doivent être approuvées ou distribuées par un administrateur. Dans la configuration Synapse, définissez les deux valeurs :

enable_registration: true
registration_requires_token: true

Les deux conditions sont requises : le paramètre de jeton exige un jeton lors de l’inscription, et l’inscription elle-même doit être activée. Appliquez la modification et redémarrez Synapse. Les comptes existants et les jetons créés précédemment ne seront pas supprimés par cette modification.

Créer un jeton à usage limité

Synapse propose une API d'administration avec jeton d'enregistrement. Les requêtes nécessitent un jeton d'accès administrateur. Par exemple, cette requête crée un jeton permettant d'effectuer un enregistrement :

curl -sS -X POST "$SYNAPSE_URL/_synapse/admin/v1/registration_tokens/new" \
  -H "Authorization: Bearer $ADMIN_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"uses_allowed": 1}'

Remplacez les variables d'environnement par l'URL de base de votre serveur et un jeton d'accès administrateur. Conservez ce jeton confidentiel et évitez de coller des commandes contenant vos identifiants réels dans les journaux partagés ou les messages d'assistance. L'API accepte également une durée de validité en millisecondes depuis l'époque Unix. Utilisez un jeton à usage unique pour chaque invitation et définissez une date d'expiration lorsque votre système peut la calculer et la gérer de manière fiable. Un jeton sans limite peut avoir un nombre d'utilisations illimité et aucune date d'expiration ; vérifiez donc les champs renvoyés avant de le diffuser.

Pour consulter les jetons, un administrateur peut appeler la fonction appropriée GET /_synapse/admin/v1/registration_tokens. La réponse indique les utilisations autorisées, les inscriptions en attente, les inscriptions terminées et la date d'expiration. Si un jeton est divulgué, mettez à jour ses utilisations autorisées à zéro ou supprimez-le via l'API d'administration documentée. Un jeton est un identifiant d'inscription, et non une invitation à une salle Matrix ; il n'ajoute pas automatiquement le nouveau compte à une salle.

Note importante concernant la compatibilité : l’API d’administration des jetons d’enregistrement de Synapse est désactivée lorsque l’intégration de Matrix Authentication Service (MAS) est activée. Dans ce cas, utilisez l’API d’administration MAS ou l’interface de ligne de commande MAS documentée pour votre déploiement. Ne présumez pas qu’une commande de jeton Synapse fonctionnera de la même manière avec MAS.

Option 3 : Ajouter des contrôles à l’inscription publique

Si votre objectif est de permettre à quiconque de demander un compte, exiger des jetons peut s'avérer trop restrictif. La configuration de Synapse mentionne également les exigences relatives aux CAPTCHA et aux identifiants tiers comme méthodes de vérification possibles. Le CAPTCHA dépend d'un fournisseur correctement configuré et peut engendrer des coûts supplémentaires en matière d'accessibilité et de confidentialité. Exiger une adresse e-mail ou un numéro de téléphone peut complexifier la configuration et la vérification ; cela ne revient pas à approuver chaque compte. Avant d'imposer l'utilisation d'un identifiant tiers comme critère de validation, assurez-vous de vérifier quels services de vérification votre version et votre flux client prennent réellement en charge.

La limitation du débit est utile en complément de ces contrôles car elle réduit les requêtes répétées, mais elle ne détermine pas qui est autorisé à s'inscrire. Surveillez les tentatives d'inscription et les journaux du serveur, et ajustez les limites en fonction de votre trafic et de votre déploiement. Évitez de copier d'anciens extraits de configuration sans vérifier votre version de Synapse : les options d'inscription et de service d'identité ont évolué.

Ce que l'inscription de clôture change — et ne change pas —

• Il contrôle les nouveaux comptes locaux. La désactivation de l'enregistrement bloque le processus normal de création de comptes sur votre serveur domestique.
• Cela ne supprime pas les comptes. Les utilisateurs existants conservent leurs comptes, sauf si vous les suspendez ou les désactivez séparément.
• Cela ne désactive pas la fédération. Les utilisateurs d'autres serveurs d'accueil peuvent toujours communiquer avec les utilisateurs et les salons locaux, sous réserve des paramètres d'appartenance aux salons et de fédération.
• Cela ne rend pas une salle accessible uniquement sur invitation. Les règles d'accès à une salle sont un paramètre distinct ; les jetons d'inscription ne remplacent pas les invitations.
• Cela ne bloque pas nécessairement tous les chemins d'approvisionnement. Les API d'administration, un secret partagé configuré, les services applicatifs et les paramètres de création de compte SSO nécessitent un examen distinct.

Une règle de proxy inverse masquant l'URL d'enregistrement peut constituer un contrôle supplémentaire au niveau du réseau, mais elle risque de perturber le flux client et ne remplace pas la configuration du serveur d'accueil. Privilégiez la configuration au niveau de l'application et testez le déploiement après chaque modification du proxy.

Vérifiez le résultat

1. Vérifiez la source de configuration effective, y compris tout montage de liaison de conteneur ou toute configuration générée, pour les valeurs d'enregistrement prévues.
2. Redémarrez Synapse et consultez les journaux de démarrage pour détecter les erreurs YAML ou les paramètres non pris en charge.
3. Depuis un client Matrix déconnecté, essayez de lancer une nouvelle inscription. Si l'inscription est désactivée, le processus ne devrait pas proposer d'inscription publique fonctionnelle. Si l'inscription avec jeton requis est activée, une requête sans jeton valide ne devrait pas aboutir.
4. Pour l'enregistrement des jetons, effectuez un test avec un jeton temporaire à usage unique et vérifiez qu'il ne permet de créer qu'un seul compte. Consultez la réponse de l'API d'administration pour obtenir les informations relatives à la création completed, pendingà la date et à l'expiration du compte.
5. Testez un chemin SSO configuré séparément et tous les scripts de provisionnement de comptes. Vérifiez qu'ils se comportent conformément à votre politique d'accès.

N’utilisez pas de jeton d’invitation réel pour un compte de test, sauf si vous comptez l’utiliser. Si le paramètre semble inefficace, vérifiez d’abord que vous avez bien modifié le fichier chargé par Synapse et que le service a redémarré. Ensuite, vérifiez la présence d’un secret d’enregistrement partagé, de l’enregistrement automatique SSO ou d’un autre mécanisme d’approvisionnement fiable.

Références officielles

• Manuel de configuration de Synapse 1.160 : paramètres d’enregistrement
• API d'administration du jeton d'enregistrement Synapse
• Guide d'installation de Synapse : enregistrement d'un utilisateur
• API d'enregistrement de secret partagé Synapse
• Spécification de l'API client-serveur Matrix

La documentation de configuration versionnée et de l'API d'administration de Synapse fait foi pour les noms d'options et les champs de requêtes. Les instructions ci-dessus ne tiennent pas compte d'un système d'exploitation, d'une image de conteneur, d'un proxy inverse ou d'un client Matrix en particulier ; veuillez vérifier les spécificités de votre déploiement avant d'appliquer des modifications.