Permitir que los usuarios autorizados creen salas de Jitsi con inicio de sesión de Keycloak.

Para limitar la creación de salas de Jitsi Meet a usuarios específicos, se requiere la autenticación de los anfitriones y la emisión de credenciales únicamente a las cuentas aprobadas. Para las nuevas instalaciones autoalojadas, Jitsi recomienda ahora la autenticación basada en tokens; esta guía utiliza Keycloak como proveedor de identidad y permite que los invitados se unan a las salas solo después de que un anfitrión aprobado las inicie.

1. Verifique la implementación y elija sus cuentas de host.

Estas instrucciones están dirigidas a una instalación autohospedada de Jitsi Meet a partir de paquetes Debian o Ubuntu, con acceso de administrador a Prosody, Nginx y la configuración web de Jitsi. Se presupone que Keycloak ya está instalado o puede implementarse de forma segura. Prosody es el servidor de mensajería XMPP; un JSON Web Token (JWT) es una credencial firmada que se utiliza para demostrar que un usuario se ha autenticado. Keycloak es un proveedor de identidad que gestiona el inicio de sesión de los usuarios.

El manual de Jitsi marca la receta antigua de dominio seguro con nombre de usuario y contraseña como obsoleta y dirige las nuevas instalaciones a la autenticación por token. Sus instrucciones de autenticación actuales se actualizaron el 5 de octubre de 2026. Si ya utiliza Docker, no copie las rutas de los paquetes que aparecen a continuación: la guía de configuración oficial de Docker utiliza variables de entorno como ENABLE_AUTH, ENABLE_GUESTS, y AUTH_TYPE.

Antes de editar, anote el nombre de host de su reunión pública, confirme que HTTPS funciona, haga una copia de seguridad de los archivos de configuración que planea modificar y decida qué cuentas con nombre pueden albergar reuniones. En este ejemplo, la dirección de la reunión es jitsi.example.com; reemplácela en todas partes con su host real.

2. Otorgue acceso en Keycloak únicamente a los hosts autorizados.

Crear un dominio dedicado

En la consola de administración de Keycloak, cree y seleccione un reino llamado jitsi-realm. Un reino es una colección aislada de usuarios y configuraciones de aplicaciones. Desactive el registro de usuarios abierto y evite importar automáticamente un directorio de empresa sin restricciones: con esta configuración, cualquier cuenta que pueda autenticarse en el reino aceptado puede convertirse en creador de reuniones.

Registra el cliente web de Jitsi

Cree un cliente OpenID Connect llamado jitsi. OpenID Connect (OIDC) es el protocolo de inicio de sesión que Keycloak utiliza para devolver información de identidad a Jitsi. Siguiendo el ejemplo oficial de Jitsi, introduzca estos valores exactos de devolución de llamada, ajustando el nombre de host:

• URI de redireccionamiento válida:https://jitsi.example.com/static/sso.html
• URI de redireccionamiento válida después del cierre de sesión:https://jitsi.example.com/static/logout.html
• Origen web:https://jitsi.example.com

Añade las personas permitidas

En la sección Usuarios, cree una cuenta para cada host autorizado y, a continuación, establezca la contraseña de dicho usuario en Credenciales. Utilice cuentas independientes en lugar de compartir un único inicio de sesión de administrador. Si una cuenta ya no debe crear reuniones, debe deshabilitarse o denegarse su acceso a este dominio. Si necesita restricciones para un solo grupo dentro de un dominio compartido, añada una política de autorización verificada por separado; los pasos descritos aquí no aplican automáticamente la pertenencia a grupos de Keycloak.

3. Conecta Keycloak al servidor Jitsi.

Proxy Keycloak puntos finales de reino a través de HTTPS

Configure Keycloak con el nombre de host público correcto y los encabezados de proxy inverso de confianza, luego dirija /realms/las solicitudes desde su nombre de host Jitsi a su oyente privado de Keycloak. Para una instancia de Keycloak disponible en 127.0.0.1:18080, agregue el siguiente bloque de ubicación dentro del bloque de servidor HTTPS Jitsi Nginx existente, antes de las rutas generales de Jitsi:

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

Esto presupone que Keycloak es accesible localmente en ese puerto; reemplace el puerto de origen para su implementación. No exponga innecesariamente la consola de administración ni el puerto de backend de Keycloak. Consulte la documentación del proxy inverso de Keycloak para obtener información sobre el proxy de producción y los controles de nombre de host.

Requerir tokens en Prosody

Editar /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. Agregue la configuración del emisor y la audiencia, luego actualice el archivo principal existente VirtualHostpara usar la autenticación por token. Combine estas líneas con su otra configuración; no cree una segunda copia de ese bloque de host:

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"

Para el acceso de invitados, agregue un guest.jitsi.example.comhost virtual separado con authentication = "jitsi-anonymous", c2s_require_encryption = false, y el smacksmódulo, como se muestra en las instrucciones de Jitsi. Este es un dominio XMPP interno: no cree un DNS público ni un certificado separado para él. En la lista de módulos del host principal existente, agregue persistent_lobby; en la conference.jitsi.example.comlista de módulos del componente MUC existente, agregue muc_wait_for_host. Un MUC es el componente de chat multiusuario que mantiene las salas de conferencias. Conserve los módulos ya listados.

Configurar el flujo de inicio de sesión del navegador

En /etc/jitsi/meet/jitsi.example.com-config.js, agregue anonymousdomain: 'guest.jitsi.example.com'al hostsobjeto existente. Agregue la configuración OIDC documentada por Jitsi:

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

Estos valores implementan el flujo de inicio de sesión con código de autorización mediante PKCE (Proof Key for Code Exchange), una protección para la autorización basada en navegador. El manual de Jitsi indica específicamente que se debe dejar jicofo.confla autenticación deshabilitada para el modo token; no copie su bloque de autenticación de dominio seguro XMPP obsoleto.

Validar y recargar los servicios

Verifique la sintaxis de Nginx y luego reinicie solo los servicios que aparecen en las instrucciones de autenticación de tokens actuales. Realice estos cambios durante una ventana de mantenimiento si su servidor Jitsi ya está en uso.

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

4. Evite estos errores de permisos e inicio de sesión.

• Todos pueden crear una sala: confirmen que el anfitrión principal de Prosody esté autenticado mediante token, que no se permiten tokens vacíos y que el anfitrión invitado sea independiente. Realicen la prueba en una sesión de navegador limpia, no en una que aún tenga una sesión iniciada válida.
• Los usuarios autorizados no pueden iniciar sesión: compare el emisor del reino de Keycloak, el nombre de host HTTPS público, el ID de cliente, la URI de redireccionamiento y la Prosody cache_keys_url. Un error en la redireccionamiento del navegador no indica que los permisos del usuario sean correctos.
• Los invitados nunca entran en una sala: compruebe el dominio anónimo tanto en Prosody como en Jitsi config.js, además de los módulos wait-for-host. Un estado de espera en el lobby o para invitados es diferente de un fallo de autenticación.

5. Verifica quién puede crear una nueva reunión.

Abre una URL de sala que nunca hayas usado en una ventana de navegación privada sin iniciar sesión. El invitado no debería poder iniciar la conferencia como anfitrión. A continuación, inicia sesión como usuario autorizado de Keycloak y crea esa sala; un invitado debería poder unirse si has habilitado el dominio de invitado. Por último, prueba con una cuenta deshabilitada o no autorizada y confirma que no puede autenticarse ni crear una nueva sala.

Si alguna prueba falla, inspeccione sudo journalctl -u prosody -u nginx --since "10 minutes ago"junto con los eventos de autenticación de Keycloak, sin publicar tokens ni contraseñas de los registros. La solución se confirma solo cuando una cuenta autorizada puede crear una sala nueva y un usuario no autenticado no puede.