Authelia 4.39 en pymes: MFA, proxy y grupos
Guía técnica para poner Authelia delante de aplicaciones internas: MFA, grupos, proxy, PostgreSQL, permisos y prueba de baja.
Un panel interno expuesto detrás de una contraseña única ya crea una deuda operativa. Authelia 4.39.20, publicado el 26 de mayo de 2026, agrega autenticación multifactor, reglas por grupo y control delante de aplicaciones web mediante proxy. Para pymes con ERP, tickets o tableros internos, esta guía explica dónde vive la identidad, qué guarda PostgreSQL y cómo probar una baja de acceso.
Dónde aparece el acceso que queda abierto
La escena se repite en municipios chicos, clínicas y cooperativas: un dominio interno queda publicado para proveedores, administración y soporte, con una contraseña que cambió pocas veces. El objeto que delata el problema es un usuario llamado admin compartido por tres personas. Cuando alguien se va, nadie sabe qué sesión quedó vigente ni qué aplicación puede seguir abriendo. Authelia se define en su documentación como un servidor abierto de autenticación y autorización para MFA y SSO mediante portal web. El proyecto lo ubica delante de aplicaciones con proxies: nginx, Traefik, Caddy, Envoy o HAProxy. El release v4.39.20 sirve como referencia actual de versión para instalaciones nuevas. El antagonista es el usuario genérico que conserva acceso después de la baja. El dato global viene de Stack Overflow 2025: 15,47% de los respondentes dijo haber respaldado una herramienta abierta usada por más personas que ellos mismos. En pymes, esa decisión rara vez empieza por ideología; empieza cuando una pieza abierta permite mirar el flujo, guardar configuración y hacer una prueba de recuperación.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, el usuario entra a tablero.empresa.com o tickets.empresa.com. Segundo, el proxy detecta que esa ruta necesita control y consulta a Authelia. Tercero, Authelia pide primer factor y segundo factor, que puede ser TOTP, passkey u otro método disponible en la instalación. Cuarto, compara usuario, grupo, dominio, ruta y red contra las reglas de acceso. Quinto, si la regla permite el ingreso, el proxy reenvía la petición a la aplicación interna. Sexto, PostgreSQL guarda datos persistentes de Authelia; Redis puede guardar estado compartido cuando hay alta disponibilidad. La aplicación recibe solo tráfico autorizado, y el log de proxy ayuda a reconstruir hora, dominio, IP y respuesta. Authelia recibe identidad y contexto de acceso; entrega decisión. PostgreSQL recibe registros persistentes de configuración y estado; entrega consulta y restauración. El proxy recibe HTTP y TLS; entrega tráfico filtrado. IT administra grupos, secreto de sesión, correo de recuperación, permiso de administración, backup y prueba de baja. Si Authelia cae, conviene tener definido qué apps quedan cerradas y qué acceso de emergencia queda documentado.
Qué se instala o configura primero
La pila concreta usa Authelia 4.39, PostgreSQL 17, Redis si hay más de una instancia, Caddy o nginx como proxy, DNS, TLS, SMTP para notificaciones, grupos por área y un repositorio versionado de configuración. El primer entregable verificable es una app protegida con dos grupos: administración puede entrar, proveedores quedan bloqueados, y un usuario de baja falla después de quitarlo del grupo. El costo mensual para un piloto puede ubicarse entre USD 25 y USD 90, equivalentes a ARS 38.000 y ARS 136.800 al dólar oficial de venta de ARS 1.520 por dólar. Ese rango cubre VM, base, backup, monitoreo simple y prueba mensual. La licencia del software. USD 0; integración con directorio, migración de usuarios y revisión de políticas se presupuestan aparte. UMSA suele empezar por el inventario de aplicaciones expuestas: dominio, proxy, usuarios, grupo dueño, segundo factor, logs y ruta de restauración. La pyme gana control cuando cada app tiene regla escrita y cada persona tiene una salida comprobable.
Dónde se rompe y cómo probarlo
El primer riesgo aparece con rutas sin protección. La señal es una URL interna que evita el portal y entra directo al backend. La prueba intenta acceder por dominio alterno, IP y ruta antigua; todo debe pedir autenticación. El segundo riesgo aparece con grupos heredados. La señal es un proveedor que mantiene permiso por pertenecer a un grupo amplio. La prueba crea un usuario de proveedor, lo quita del grupo y confirma rechazo inmediato. El tercer riesgo aparece con recuperación débil. La señal es una cuenta administradora sin segundo factor o con correo compartido. La prueba cambia el método de recuperación en entorno controlado y registra quién puede aprobarlo. El cuarto riesgo aparece con almacenamiento sin restauración. La documentación de PostgreSQL storage exige pensar la base como parte central del servicio. La prueba restaura Authelia en otra VM y confirma que reglas, usuarios y eventos sigan consultables. El quinto riesgo aparece con proxy sin cabeceras correctas. La introducción de integración con proxies deja claro que Authelia trabaja junto al proxy. La prueba revisa cabeceras, esquema HTTPS, dominio y cookie después de cada cambio. Authelia ordena accesos cuando identidad, grupo, regla y proxy quedan escritos. La pregunta para una pyme es concreta: sí un usuario se va hoy, ¿qué aplicación prueba mañana que la baja funciónó?
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.