Estrategia de realms en Keycloak: cuándo usar single, multi-región o por unidad de negocio
· IAM · IDPTrust
Cuando montas Keycloak por primera vez, la pregunta no es técnica — es estratégica: ¿cuántos realms?
Parece una decisión menor. No lo es. La estructura de realms condiciona durante años el modelo operativo, la experiencia de usuario, la complejidad del equipo y —si te equivocas— el coste de una migración que puede llevar meses.
No hay una respuesta universal. Hay patrones que funcionan mejor en ciertos contextos, y trade-offs que conviene entender antes de decidir.
Qué es un realm en Keycloak (y por qué importa)
Un realm es una frontera de aislamiento lógico dentro de una instancia de Keycloak. Cada realm tiene:
- Sus propios usuarios, roles y grupos
- Sus propios clients (aplicaciones)
- Sus propios proveedores de identidad federados (SAML, OIDC, LDAP)
- Sus propios flujos de autenticación, themes y políticas
- Sus propios tokens y claves de firma
Dos realms son, a efectos prácticos, dos directorios separados dentro del mismo despliegue. Un usuario en el realm A no existe en el realm B. Tampoco hay SSO nativo entre realms — necesitas federación explícita.
Una precisión clave que vamos a usar más adelante: el realm es la unidad de tenant lógico, no la unidad de despliegue. La unidad de despliegue es la instancia de Keycloak (JVM + base de datos). Esto importa especialmente al hablar de multi-región.
Los tres modelos más habituales
1. Single realm
Un único realm para toda la organización.
- Cuándo: empresa con un perímetro homogéneo, catálogo de apps moderado, SSO universal como requisito duro.
- Pros: operación simple, SSO trivial, políticas centralizadas, auditoría unificada, una sola superficie que mantener.
- Contras: sin aislamiento entre dominios, difícil delegar administración, cualquier cambio sensible (flujos, políticas, themes) impacta a toda la organización.
Es la opción por defecto correcta para muchas empresas medianas. Si no tienes una razón explícita para tener más de un realm, no la inventes.
2. Multi-región (LATAM, EMEA, APAC...)
Un realm por región — y, en la práctica, una instancia de Keycloak por región.
Aquí conviene ser preciso, porque es donde se cometen los errores conceptuales más caros. El realm en sí mismo no se "despliega" en una región: vive dentro de una instancia. Si lo que te preocupa es residencia de datos o marcos legales distintos, lo que tienes que replicar geográficamente es la instancia completa (con su base de datos en la jurisdicción correcta). Los realms son la frontera lógica de cada despliegue.
- Cuándo: presencia real con marcos legales distintos, residencia de datos por país (GDPR en la UE, LGPD en Brasil, etc.), equipos regionales con autonomía operativa.
- Pros: soberanía del dato real, cumplimiento más fácil de demostrar, IdPs locales sin acoplar regiones, blast radius limitado por región.
- Contras: SSO entre regiones no es automático, los usuarios globales son un caso especial, multiplicas el trabajo operativo por el número de regiones, la gobernanza global se vuelve más compleja.
3. Por unidad de negocio o departamento
Un realm por área de negocio (RRHH, Finanzas, Producto) o por empresa dentro de un holding.
- Cuándo: holdings con divisiones autónomas, post-M&A donde cada empresa mantiene su identidad, compliance muy distinto entre unidades, necesidad real de delegar administración por área.
- Pros: delegación clara de responsabilidades, flujos adaptados a cada negocio, aislamiento útil cuando los riesgos difieren, posibilidad de IdPs corporativos distintos por unidad.
- Contras: los empleados que cruzan unidades son un dolor de cabeza, el SSO corporativo entre áreas requiere federación explícita, la gobernanza se fragmenta, y branding y políticas pueden divergir sin querer.
Modelos híbridos (la realidad)
Pocas organizaciones grandes se quedan en un único patrón puro. Lo habitual es combinar:
- Multi-región a nivel de instancia + multi-unidad de negocio dentro de cada región
- Realm separado para empleados (workforce) y otro para usuarios externos (partners, contratistas)
- Realm master reservado a administración + realms operativos por unidad
El híbrido bien diseñado es potente. La trampa es llegar al híbrido por accidente — empezar con un realm, ir añadiendo más sin estrategia, y descubrir tres años después que tienes un mapa que nadie entiende y que cuesta más operar que cualquier rediseño.
Tabla comparativa
| Modelo | Aislamiento | Coste operativo | SSO nativo | Personalización | Encaje típico |
|---|---|---|---|---|---|
| Single realm | Bajo | Bajo | Total | Limitada | Empresa con perímetro homogéneo |
| Multi-región | Alto (a nivel de instancia) | Medio-alto | No entre regiones | Por región | Multinacional con residencia de datos |
| Por unidad de negocio | Medio-alto | Medio-alto | No entre unidades | Por unidad | Holdings, post-M&A |
Cómo decidir: cuatro preguntas
No empieces por el modelo. Empieza por las restricciones.
¿Hay requisitos de residencia de datos en más de una jurisdicción? Si la respuesta es sí, multi-región a nivel de instancia deja de ser opcional. No es una decisión de arquitectura — es una decisión de cumplimiento.
¿Quién administra qué? Si necesitas delegar la administración a unidades autónomas sin que se pisen, el multi-realm por unidad de negocio es casi obligado.
¿Tu equipo puede operar N realms (y N instancias si aplica)? Sin IaC, sin monitorización por realm/instancia y sin runbooks claros, todo modelo multi-* se convierte en deuda operativa rápido. Un single realm bien operado supera a un multi-realm mal operado en cualquier métrica que importe.
¿Necesitas SSO universal entre todas las apps y usuarios? Si la respuesta es sí y no quieres montar federación explícita entre realms, el single realm gana por defecto.
Errores que vemos repetirse
- Crear un realm por aplicación. El realm no es un workspace por proyecto. Cada realm añade superficie operativa real. Si tus apps comparten usuarios, comparten realm.
- Confundir aislamiento lógico con aislamiento de despliegue. Dos realms en la misma instancia comparten JVM, base de datos y radio de fallo. Si necesitas aislamiento físico, necesitas instancias separadas.
- Asumir que el SSO entre realms es automático. No lo es. Hay que diseñarlo con identity brokering o federación, y tiene su propio coste operativo y de mantenimiento.
- No planificar la migración. Cambiar de modelo a posteriori (consolidar realms o partirlos) es un proyecto de meses, no una tarea de sprint.
- Multi-región sin entender qué se replica. La instancia se replica, no el realm individual. Si lo que te preocupa es residencia de datos, asegúrate de que la base de datos también vive en la jurisdicción correcta.
La decisión
No existe el modelo correcto en abstracto. Existe el modelo correcto para tu organización en los próximos tres años.
Las preguntas útiles no son técnicas:
- ¿Dónde van a estar tus usuarios y tus datos en 2029?
- ¿Cuánta autonomía vas a delegar a unidades regionales o de negocio?
- ¿Qué tamaño tendrá el equipo que opera esto?
Responde esas tres y el modelo casi se elige solo.
Si quieres trabajar la decisión con tu contexto concreto, hablamos.
En IDPTrust somos especialistas en Keycloak. Diseñamos arquitecturas de realms para organizaciones que no pueden permitirse equivocarse en esta decisión.