Técnico
Authelia 4.39 en pymes: OIDC, LDAP y cortes de sesión
Guía técnica para poner Authelia delante de aplicaciones internas: OIDC, LDAP, reglas de acceso, sesiones, backup, baja de usuarios y prueba de salida.
Un proxy de autenticación corta o deja pasar una solicitud antes de que la aplicación responda. Authelia 4.39.28 permite ubicar ese control delante de sistemas internos, usar LDAP como fuente de usuarios y entregar OIDC a aplicaciones compatibles. Para una pyme o municipio chico, la decisión técnica es separar login, regla de acceso y sesión antes de sumar otra contraseña local.
Dónde aparece el login que nadie quiere auditar
El problema operativo aparece cuando cada aplicación tiene usuarios propios, bajas manuales y permisos escritos en una planilla de altas. El antagonista es el login compartido del proxy viejo: todos saben que existe, nadie sabe quién lo usó ayer. En una municipalidad chica del Gran Mendoza, una ventanilla de trámites, un panel de cámaras y un sistema de tickets pueden terminar con tres formas distintas de entrar. La evidencia visible es una hoja plastificada con usuarios tachados y flechas hacia grupos que ya no existen. La versión Authelia v4.39.28 fue publicada el 17 de septiembre de 2026. La documentación de LDAP define dirección, esquema, timeout, StartTLS, grupos, filtros y usuario de servicio. El proveedor OpenID Connect 1.0 permite que aplicaciones con cliente OIDC usen Authelia como proveedor de identidad. La cifra que frena el entusiasmo por otra pantalla de login viene de la encuesta Stack Overflow 2025: 45,5% de los encuestados usa entre una y cinco aplicaciones de software en su trabajo principal, y 35,4% usa entre seis y diez. Cada sistema nuevo agrega una baja, una contraseña y un registro que alguien debe mirar. Una sesión sin dueño termina en soporte.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, el usuario entra a una aplicación interna detrás de Nginx, Traefik o Caddy. Segundo, el proxy redirige a Authelia si no hay sesión válida. Tercero, Authelia consulta LDAP u OpenLDAP para validar usuario, grupo y atributos. Cuarto, Authelia aplica reglas de acceso: dominio, ruta, grupo, red, método y segundo factor. Quinto, si la aplicación habla OIDC, Authelia entrega tokens firmados y datos de identidad; si usa proxy auth, entrega cabeceras controladas. Sexto, Redis o almacenamiento local guardan sesiones y estados transitorios; PostgreSQL guarda datos persistentes cuando se configura como backend. Séptimo, el backup copia configuración, secretos, base y reglas; la restauración se prueba entrando con un usuario habilitado y rechazando uno dado de baja. Los permisos se escriben por grupo. Sistemas lee logs; mesa de ayuda fuerza cierre de sesión; gerencia aprueba altas; IT administra secretos y certificados. La señal de falla aparece cuando una baja en LDAP no corta acceso en la aplicación protegida.
Qué se instala o configura primero
La pila inicial puede usar Authelia 4.39.28, OpenLDAP o Active Directory, Redis, PostgreSQL 18, proxy TLS, correo para notificaciones, segundo factor y una aplicación piloto. Con dólar oficial venta de ARS 1540, un alcance para cinco aplicaciones internas puede ubicarse entre USD 600 y USD 1.400, es decir entre ARS 924.000 y ARS 2.156.000. Incluye configuración, reglas, clientes OIDC, backup, prueba de baja y documentación operativa. No incluye compra de llaves FIDO2 ni migración de todas las aplicaciones. UMSA puede empezar con GLPI, panel de monitoreo y repositorio interno. El entregable verificable es una matriz de aplicaciones, grupos, rutas, segundo factor y tiempo de sesión. La prueba de salida toma un usuario de ensayo, lo saca del grupo LDAP y confirma que Authelia corta el acceso sin tocar cada aplicación. La nota sobre Passbolt 5.15 en cámaras completa el criterio: Authelia decide quién entra; Passbolt guarda secretos y deja vencimiento, dueño y grupo para contraseñas que no deben vivir en chats.
Dónde se rompe y cómo probarlo
El primer riesgo es escribir reglas demasiado amplias. La señal aparece cuando un grupo general entra a rutas administrativas. La prueba ejecuta accesos por ruta con un usuario de gerencia, uno de soporte y uno dado de baja. El segundo riesgo es usar LDAP sin TLS. La documentación permite ldap, ldaps o ldapi, y StartTLS solo cuando corresponde. La prueba captura configuración, valida certificado y rechaza conexión insegura en producción. El tercer riesgo es perder secretos de OIDC. La señal aparece cuando una restauración levanta el servicio, pero los clientes no validan tokens. La prueba recupera configuración, claves, base y proxy en un entorno separado y abre una aplicación con OIDC. El cuarto riesgo es no revisar sesiones activas. La prueba baja un usuario en LDAP, espera la ventana configurada y confirma que la aplicación pide login otra vez. Authelia sirve cuando la baja se prueba con una cuenta real de ensayo. El día que una persona cambia de área, la pregunta es simple: ¿qué aplicación siguió abierta después del cambio de grupo?
