Keycloak 26.7 en pymes: grupos, sesiones y corte
Guía para instalar Keycloak con grupos, sesiones persistidas, permisos por aplicación y prueba de salida sin perder usuarios.
Un realm de Keycloak agrupa usuarios, clientes, sesiones y reglas de acceso en un ámbito administrativo. En una pyme, ese ámbito define quién entra al ERP, al tablero y a la mesa de ayuda, y qué ocurre cuando una persona cambia de área. Keycloak 26.7.0 agrega mejoras de administración y aprovisionamiento. Esta guía baja la instalación a datos, permisos, costo y prueba de corte.
Dónde aparece el usuario sin dueño
El síntoma se ve cuando soporte desactiva una cuenta en una aplicación y otra conserva acceso hasta el próximo cambio de contraseña. Keycloak publicó 26.7.0 el 9 de julio de 2026; la release incluye SCIM en vista previa para aprovisionar usuarios y grupos, guías de reverse proxy y step-up authentication para clientes SAML. La novedad vale si el equipo mide el flujo completo. Una sesión vieja alcanza para mantener acceso activo. El dato global viene de Stack Overflow 2025: más de 49.000 respuestas de 177 países, con PostgreSQL entre las bases que los equipos quieren seguir usando. Keycloak guarda sesiones persistidas en la base desde la línea 26; por eso la elección de PostgreSQL, backup y mantenimiento pesa tanto como la pantalla de login. El riesgo diario está en la cuenta prestada. En una clínica privada de Godoy Cruz, una credencial anotada en una etiqueta blanca pegada al monitor permite entrar rápido a facturación; deja de servir cuando auditoría pide saber qué usuario consultó una historia administrativa.
Cómo funciona por dentro
El flujo tiene seis pasos. Primero, sistemas crea un realm para la organización y define clientes para ERP, tablero, mesa de ayuda y portal interno. Segundo, carga usuarios o conecta un directorio existente. Tercero, arma grupos por área: administración, ventas, soporte, dirección y auditoría. Cuarto, Keycloak recibe usuario, contraseña, segundo factor o identidad externa y entrega tokens firmados a cada aplicación. Quinto, PostgreSQL guarda usuarios, sesiones persistidas, eventos y configuración. Sexto, el backup copia base, configuración exportada y secretos; una prueba desactiva un usuario y revisa que pierda acceso en todas las aplicaciones. Keycloak administra autenticación, federación, clientes, roles y eventos. Recibe credenciales y reglas de acceso; entrega tokens, claims y registros de sesión. PostgreSQL guarda el estado consultable. El proxy HTTPS recibe tráfico externo y entrega solicitudes al puerto interno. El monitoreo revisa latencia, errores de login y consumo de base. Los permisos deben quedar escritos. Mesa de ayuda puede resetear contraseña y revisar sesiones. Sistemas administra realms, clientes y actualizaciones. Dirección lee reportes. Auditoría consulta eventos sin editar configuración. Si Keycloak falla, las aplicaciones que dependen del login bloquean nuevas sesiones; por eso el plan debe incluir ventana de mantenimiento y cuenta de emergencia controlada. El registro de eventos completa la prueba: muestra login, error, cierre de sesión y cambio administrativo con usuario y hora.
Qué se instala o configura primero
La instalación inicial usa Keycloak 26.7.0, PostgreSQL 18, proxy TLS, SMTP, backup externo, monitoreo y exportación versionada de realms. La guía de base de datos de Keycloak separa configuración de conexión, pool y parámetros de producción; el Server Administration Guide ordena realms, usuarios, grupos, sesiones y eventos. Con dólar oficial vendedor a ARS 1.510, una VM de USD 30 a USD 60 queda entre ARS 45.300 y ARS 90.600 por mes. Un primer proyecto de 24 a 40 horas a USD 30/h queda entre USD 720 y USD 1.200, entre ARS 1.087.200 y ARS 1.812.000. Incluye realm, grupos, dos aplicaciones, MFA, backup y prueba de corte. Quedan fuera migración masiva de usuarios y rediseño de permisos internos. UMSA puede usar este patrón en pymes que ya tienen varias aplicaciones y una misma persona con accesos duplicados. El primer entregable verificable es simple: un usuario nuevo entra a dos sistemas, cambia de grupo y pierde acceso al sistema anterior dentro del plazo acordado.
Dónde se rompe y cómo probarlo
El primer riesgo es mezclar roles de aplicación con grupos administrativos. La señal aparece cuando un cambio de área exige editar cada sistema. La prueba mueve un usuario de ventas a soporte y revisa tokens, claims y pantallas visibles. El segundo riesgo está en sesiones que duran más que la relación laboral. La señal es un usuario desactivado con sesión activa en una aplicación. La prueba desactiva la cuenta, fuerza refresh de token y revisa logs de rechazo. El tercer riesgo aparece en actualizaciones sin ensayo. La guía de upgrading obliga a revisar cambios antes del salto. La prueba restaura una copia en staging, importa el realm, ejecuta login, MFA, salida y desactivación. El cuarto riesgo es backup incompleto. Una base recuperada sin secretos ni export del realm deja clientes inválidos. La prueba levanta otra instancia, importa configuración, conecta PostgreSQL restaurado y abre el tablero de eventos. El login único recién sirve cuando el corte también funciona.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.