Cómo restringir el registro de usuarios en un servidor Matrix autohospedado.

En un servidor Matrix autogestionado, «restringir el registro» puede significar desde impedir todos los registros públicos hasta permitir el acceso solo a quienes tengan un código de invitación. En Synapse, la opción más sencilla es deshabilitar el registro público. Si aun así desea que se unan nuevos usuarios, exija tokens de registro y asigne a cada persona un token limitado y con fecha de caducidad. Estos controles afectan a la creación de nuevas cuentas locales; no eliminan a los usuarios existentes ni deshabilitan la federación de Matrix.

Elige el control que mejor se adapte a tu servidor.

Los ejemplos que se muestran a continuación corresponden a Synapse. Dendrite, Conduit y otras implementaciones de servidores domésticos utilizan interfaces de configuración y administración diferentes. Consulte la documentación de su servidor antes de aplicar la configuración de Synapse.

Opción 1: Desactivar el registro público

Para un servidor doméstico privado, una organización pequeña o un servidor donde un administrador configura cada cuenta, desactive el registro de clientes en la configuración activa de Synapse:

enable_registration: false

Synapse documenta esta configuración como deshabilitada por defecto. Edite el archivo de configuración que carga su servicio o contenedor, valide el YAML y, a continuación, reinicie Synapse siguiendo su proceso habitual de gestión de servicios. En una implementación de Docker, la configuración puede montarse desde una ruta del host, por lo que editar un archivo con un nombre similar dentro del contenedor podría no modificar el archivo utilizado al inicio.

Con el registro desactivado, los usuarios no pueden crear nuevas cuentas mediante el flujo de registro de cliente habitual. Los administradores aún pueden crear cuentas mediante los métodos administrativos compatibles. Synapse advierte específicamente que esta configuración registration_shared_secretpermite la creación de cuentas utilizando ese secreto incluso cuando enable_registrationes falso. Trátelo como una credencial de alto impacto: manténgalo fuera de los repositorios, el chat y los volcados de entorno públicos; limite el acceso; y consérvelo solo si su flujo de trabajo administrativo lo requiere. Cualquier persona con el secreto puede crear cuentas, incluidas las de administrador.

Si utiliza OIDC, CAS u otra integración de SSO, verifique también la configuración de registro automático de dicho proveedor. Synapse documenta los parámetros de registro a nivel de proveedor, ya que, de lo contrario, el usuario podría crearse automáticamente al iniciar sesión correctamente mediante SSO por primera vez. Para OIDC, revise oidc_providers[].enable_registrationtambién la configuración de registro general.

Opción 2: Permitir el registro solo con tokens

Utilice tokens de registro cuando los miembros deban poder crear sus propias cuentas, pero los registros deban ser aprobados o distribuidos por un administrador. En la configuración de Synapse, establezca ambos valores:

enable_registration: true
registration_requires_token: true

Se requieren ambos: la configuración del token exige un token durante el registro, y el registro en sí también debe estar habilitado. Aplique el cambio y reinicie Synapse. Las cuentas existentes y los tokens creados previamente no se eliminan al modificar esta configuración.

Crea un token de uso limitado

Synapse proporciona una API de administración de tokens de registro. Las solicitudes requieren un token de acceso de administrador. Por ejemplo, esta solicitud crea un token que puede completar un registro:

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

Reemplace las variables de entorno con la URL base de su servidor principal y un token de acceso de administrador. Mantenga el token de administrador en privado y evite pegar comandos que contengan credenciales reales en registros compartidos o publicaciones de soporte. La API también puede aceptar un tiempo de caducidad en milisegundos desde la época Unix. Use un token de un solo uso para cada invitación individual y establezca una fecha de caducidad cuando su flujo de trabajo pueda calcularla y mantenerla de forma fiable. Un token sin límites definidos puede tener usos ilimitados y no tener fecha de caducidad, así que revise los campos devueltos antes de distribuirlo.

Para inspeccionar los tokens, un administrador puede llamar a GET /_synapse/admin/v1/registration_tokens. La respuesta incluye los usos permitidos, los registros pendientes, los registros completados y la fecha de vencimiento. Si se filtra un token, actualice sus usos permitidos a cero o elimínelo a través de la API de administración documentada. Un token es una credencial de registro, no una invitación a una sala de Matrix; no une automáticamente la nueva cuenta a una sala.

Nota importante sobre compatibilidad: La API de administración de tokens de registro de Synapse se desactiva cuando la integración con Matrix Authentication Service (MAS) está habilitada. En ese caso, utilice la API de administración de MAS o la CLI de MAS documentadas para su implementación. No dé por sentado que un comando de token de Synapse funcionará sin cambios con MAS.

Opción 3: Agregar controles al registro público

Si su objetivo es permitir que cualquier persona solicite una cuenta, exigir tokens puede resultar demasiado restrictivo. La configuración de Synapse también documenta los requisitos de CAPTCHA e identificadores de terceros como posibles verificaciones. CAPTCHA depende de un proveedor correctamente configurado y puede generar costos adicionales en cuanto a accesibilidad y privacidad. Exigir una dirección de correo electrónico o un número de teléfono puede añadir dependencias de configuración y verificación; no es lo mismo que aprobar cada cuenta. Confirme qué servicios de verificación son compatibles con su versión y flujo de cliente antes de establecer un requisito de 3PID como barrera.

La limitación de velocidad es útil junto con estos controles, ya que reduce las solicitudes repetidas, pero no determina quién puede registrarse. Supervise los intentos de registro y los registros del servidor, y ajuste los límites según su tráfico y despliegue. Evite copiar fragmentos de configuración antiguos sin verificar la versión de Synapse instalada: las opciones de registro y servicio de identidad han cambiado con el tiempo.

Qué cambia (y qué no cambia) el cierre del registro.

• Controla las nuevas cuentas locales. Deshabilitar el registro bloquea el flujo normal de creación de cuentas en tu servidor doméstico.
• No elimina las cuentas. Los usuarios existentes conservan sus cuentas a menos que usted las suspenda o desactive por separado.
• Esto no desactiva la federación. Los usuarios de otros servidores domésticos aún pueden comunicarse con usuarios y salas locales, sujeto a la pertenencia a la sala y la configuración de federación.
• Esto no convierte una sala en un espacio solo para invitados. Las reglas para unirse a una sala son una configuración aparte; los tokens de registro no reemplazan las invitaciones a salas.
• No necesariamente bloquea todas las rutas de aprovisionamiento. Las API de administración, un secreto compartido configurado, los servicios de la aplicación y la configuración de creación de cuentas SSO requieren una revisión por separado.

Una regla de proxy inverso que oculte la URL de registro puede servir como control adicional a nivel de red, pero puede interrumpir fácilmente el flujo de clientes y no reemplaza la configuración del servidor principal. Utilice la configuración a nivel de aplicación como control principal y pruebe la implementación real después de cualquier cambio de proxy.

Verificar el resultado

1. Verifique la fuente de configuración efectiva, incluyendo cualquier montaje de enlace de contenedor o configuración generada, para los valores de registro previstos.
2. Reinicia Synapse y revisa los registros de inicio para detectar errores YAML o configuraciones no compatibles.
3. Desde un cliente Matrix sin sesión iniciada, intente iniciar un nuevo registro. Si el registro está deshabilitado, el proceso no debería ofrecer un registro público utilizable. Si el registro requiere token, una solicitud sin un token válido no debería completarse.
4. Para el registro de tokens, pruebe con un token temporal de un solo uso y confirme que solo completa una creación de cuenta. Inspeccione la respuesta de la API de administración para obtener información sobre completed, pendingy la fecha de vencimiento.
5. Pruebe una ruta de inicio de sesión único (SSO) configurada por separado y cualquier script de aprovisionamiento de cuentas. Confirme que se comportan de acuerdo con su política de acceso.

No utilice un token de invitación real para una cuenta de prueba a menos que tenga intención de usarlo. Si la configuración parece ineficaz, verifique primero que haya modificado el archivo que Synapse carga y que el servicio se haya reiniciado. A continuación, compruebe si existe una clave secreta de registro compartida, un registro automático de SSO u otro mecanismo de aprovisionamiento de confianza.

Referencias oficiales

• Manual de configuración de Synapse 1.160: configuración de registro
• API de administración de tokens de registro de Synapse
• Guía de instalación de Synapse: registro de un usuario
• API de registro de clave compartida de Synapse
• Especificación de la API cliente-servidor de Matrix

La configuración versionada de Synapse y la documentación de la API de administración son la fuente de información fidedigna para los nombres de las opciones y los campos de solicitud. Las instrucciones anteriores no presuponen un sistema operativo, una imagen de contenedor, un proxy inverso o un cliente Matrix específicos; confirme estos detalles específicos de la implementación antes de aplicar los cambios.