Los backends legacy nunca fueron diseñados para aceptar identidad moderna
Muchas aplicaciones que funcionan dentro de una empresa — portales internos, sistemas de facturación, consolas de operaciones, paneles de administración de proveedores, herramientas legacy de línea de negocio — se construyeron antes de que SAML u OIDC fueran estándar. Típicamente reconocen al usuario no mediante tokens modernos, sino a través de una cabecera HTTP, una credencial Basic-Auth o una cookie de sesión en la que ya confían.
Migrar estas aplicaciones a SSO moderno parece sencillo en teoría: reescribir la ruta de autenticación del backend, agregar soporte SAML/OIDC y conectar la aplicación al proveedor de identidad central. En la práctica casi nunca ocurre. El código fuente puede ser antiguo, la aplicación puede ser propiedad de un proveedor, el cambio puede romper un flujo de trabajo regulado, o el coste simplemente no está justificado para una herramienta interna que funciona bien.
Las organizaciones quedan entonces atrapadas entre dos malas opciones: dejar las aplicaciones legacy fuera del perímetro de identidad moderno, o construir una integración frágil y separada para cada una. El resultado es una experiencia de usuario fragmentada, control de acceso descentralizado y lógica de identidad dispersa en el modelo legacy de cada backend.
El enfoque correcto es posicionar la capa de acceso moderna frente a la aplicación. El usuario primero pasa por la identidad central, MFA, acceso condicional y comprobaciones de confianza del dispositivo; la identidad autenticada se traduce entonces a una forma que el backend ya entiende. La aplicación obtiene una experiencia de SSO moderno sin ningún cambio de código.
Pero esta transición debe realizarse con cuidado. Si las cabeceras de identidad suplantadas del usuario se reenvían al backend sin ser eliminadas, cualquiera puede agregar su propio cabecera X-Auth-User a su solicitud y suplantar a otro usuario. El gateway debe eliminar los valores entrantes no confiables, inyectar solo la identidad de confianza que produce él mismo, y delimitar esto estrictamente por ruta.
El logout, la pérdida de sesión y el estado de identidad iniciado desde el backend también deben fluir a través del mismo motor. De lo contrario, el usuario puede aparecer desconectado en el portal mientras la sesión del backend permanece activa, o la sesión del backend puede caerse sin que la capa de acceso lo detecte.
Backend SSO no consiste en forzar la reescritura de aplicaciones legacy — se trata de poner el control de identidad moderno frente a la aplicación, y traducir de forma segura la identidad del usuario autenticado al lenguaje que el backend ya acepta.
Nuestro enfoque
Un objeto de configuración por backend, cinco formas de inyección, coordinadas con el resto del motor de acceso.
Eliminar cada valor entrante, luego inyectar el autenticado
Cada regla de inyección primero elimina cualquier copia entrante de la cabecera, cookie o valor de Authorization de destino, luego inyecta la versión derivada de la sesión autenticada. Un usuario que envíe su propio "X-Auth-User" no puede suplantar a otra persona — su cabecera se elimina antes de que el gateway agregue la de confianza.
Cinco formas de inyección para los patrones legacy más comunes
Cabeceras personalizadas (X-Auth-User, X-Forwarded-User, cualquier cosa que espere el backend), Authorization Basic para aplicaciones que requieren un par usuario:contraseña, Authorization Bearer para backends compatibles con tokens, fusión de valor de Cookie para aplicaciones que leen una cookie con nombre, y SAML-SP para backends que esperan una aserción SAML firmada. Cada inyección tiene su propia configuración; un backend puede usar varias formas a la vez.
Condiciones por inyección delimitan cada regla a las rutas correctas
Cada regla de inyección lleva su propia expresión de condición — solo aplicar en la ruta de administración, solo cuando esté presente un atributo de sesión específico, solo para un tenant. El mismo backend puede recibir identidad más rica en rutas privilegiadas y un subconjunto mínimo en rutas públicas.
La sesión perdida del backend y el logout iniciado por el backend fluyen de vuelta a través del gateway
Cuando el backend informa que la sesión del usuario se ha perdido (una forma de respuesta conocida por servicio), o cuando el propio backend desconecta al usuario, AAM detecta la señal, limpia la sesión del lado del gateway, y redirige según la política configurada. La precedencia logout-wins garantiza que la limpieza siempre se ejecute antes de cualquier inyección posterior.
Capacidades
Cinco formas de inyección, la disciplina de eliminación de entradas que las hace seguras, más las formas propias del parque Windows — inicio de sesión Kerberos delante, NTLM publicado de forma transparente detrás.
Inyección de cabecera — cualquier nombre de cabecera en el que confíe el backend
La forma más simple y común. Configure un nombre de cabecera (X-Auth-User, X-Forwarded-User, REMOTE_USER, lo que lea el backend) y la variable inteligente que produce el valor (nombre de usuario, email, lista de grupos, nombre para mostrar). La cabecera se elimina de las solicitudes entrantes, luego se vuelve a agregar desde la sesión autenticada antes de que la solicitud llegue al backend.
Inyección Authorization Basic para aplicaciones que requieren usuario:contraseña
Para aplicaciones legacy que se autentican mediante HTTP Basic, el gateway inyecta Authorization: Basic
Inyección Authorization Bearer para backends compatibles con tokens
Para backends que ya hablan tokens Bearer (APIs internas, microservicios, aplicaciones modernas de intranet) AAM inyecta Authorization: Bearer
Inyección de valor de cookie con fusión segura en una sola cabecera
Las aplicaciones que leen la identidad de una cookie con nombre se atienden con inyección de valor de cookie. El gateway fusiona el par name=value inyectado en la cabecera Cookie de la solicitud sin sobrescribir las otras cookies — la más propensa a errores de las cuatro formas de estilo cabecera, manejada con lógica de fusión explícita en lugar de sobrescrituras ingenuas.
Inyección SAML-SP — una aserción SAML firmada por solicitud
Para backends que esperan una aserción SAML firmada en cada solicitud, el gateway acuña una aserción SAML 2.0 desde la sesión autenticada, la firma con la clave de firma SAML de AAM, y la reenvía en la cabecera configurada al backend. Típico para integraciones de federación de identidad del sector público y backends SaaS empresariales. El usuario inicia sesión con un IdP moderno; el backend recibe una aserción SAML fresca y delimitada en cada solicitud.
Disciplina de eliminación de entrada aplicada a cada valor inyectado
Cada inyección está emparejada con una eliminación entrante del mismo destino. Un usuario que establezca X-Auth-User en su propia solicitud, que envíe una Cookie falsificada con un valor de identidad manipulado, o que reproduzca una cabecera Authorization de otra parte no puede hacer que el valor supere el gateway. La inyección solo se ejecuta después de que la eliminación haya liberado el slot.
Condiciones por inyección para alcance y precedencia
Cada regla de inyección puede adjuntar una condición — mismo lenguaje de expresión que la política de acceso condicional. Solo inyectar en la ruta de administración; solo inyectar cuando el usuario está en un grupo específico; solo inyectar la variante privilegiada cuando esté presente un atributo. Las condiciones se compilan de forma segura respecto a la precedencia ACL para que múltiples reglas en un backend se compongan correctamente.
Protección solo-autenticado alrededor de cada inyección
Todas las inyecciones están protegidas detrás del estado autenticado — se ejecutan solo cuando la solicitud lleva una sesión AAM válida. Un usuario que evite la autenticación a través de una ruta mal configurada no puede recibir accidentalmente credenciales de backend inyectadas; una solicitud anónima siempre llega al backend sin inyección.
Inicio de sesión Kerberos — al usuario de Windows se le reconoce sin pedirle contraseña
Un navegador unido al dominio negocia SPNEGO con la pasarela y el usuario inicia sesión con la cuenta de Windows que ya tiene — sin segunda contraseña y sin portal adicional. A partir de ahí el backend recibe la identidad mediante la forma de inyección que entiende, de modo que una aplicación heredada gana inicio de sesión único silencioso sin tocar una línea de su código. La delegación de identidad al backend en nombre del usuario queda deliberadamente fuera del alcance: ata la pasarela a un modelo de confianza de dominio que la mayoría de los entornos está abandonando, y las formas de inyección cubren la misma necesidad con un radio de impacto mucho menor.
NTLM publicado de forma transparente — el parque heredado sigue funcionando
Las aplicaciones Windows antiguas que negocian NTLM se publican sin modificación. La plataforma reconoce el esquema, marca la conexión como privada — nunca se comparte ni se reequilibra — y la fija al servidor que emitió el desafío; eso es exactamente lo que permite que NTLM sobreviva a un proxy. Sin agente en el servidor, sin reescrituras, sin excepciones en el firewall.
Profundidad operacional
Los mecanismos que hacen segura la inyección a nivel de cabecera en el borde de acceso.
Apilamiento de condiciones seguro respecto a la precedencia en tiempo de compilación
Las condiciones por inyección se componen con otras decisiones basadas en ACL del gateway (estado de autenticación, política de acceso, selección de backend). El compilador de condiciones utiliza un patrón de entradas adicionales para que las condiciones de inyección siempre se evalúen después de la autenticación y la política, nunca antes — una regla por inyección no puede invertir accidentalmente el resultado de una decisión de política de mayor precedencia.
Fetches de variables condicionales-frontend a través del dispatcher
Cuando una inyección necesita un valor que no está en la bolsa de sesión — un valor derivado de una fetch por solicitud (expansión de grupos, búsqueda de atributos) — el dispatcher emite una fetch condicional que solo se ejecuta cuando la condición de la inyección coincide. Los backends que nunca ven una inyección nunca pagan el coste de fetch del valor.
Detección de sesión perdida del backend con firma de respuesta configurable
Cada servicio puede declarar la firma de respuesta que significa «mi sesión se ha perdido» — un código de estado específico, una cabecera de respuesta específica, un marcador en el cuerpo. Cuando el gateway ve esa firma, establece un flag de sesión perdida, limpia la sesión del lado del gateway, y redirige según la política configurada.
Limpieza del logout iniciado por el backend y cadena de redirección
Cuando el propio backend desconecta al usuario — típicamente respondiendo con una firma de logout conocida — el gateway ejecuta una limpieza en tres pasos: limpiar las cookies del lado del gateway, eliminar el registro de sesión, y redirigir a través del destino configurado. La precedencia logout-wins garantiza que esta ruta supere cualquier inyección en vuelo.
Manejo de valores cifrados, nunca registrados en texto claro
Las credenciales y tokens utilizados por las inyecciones se almacenan cifrados en el almacén de configuración y nunca se escriben en los logs de acceso en texto claro. Las entradas de auditoría registran que una inyección se ejecutó en una solicitud, no qué valor llevaba. Los operadores ven la política; la carga en el cable permanece en el cable.
Reautenticación silenciosa cuando se pierde la sesión del backend
Cuando un backend pierde su propia sesión y la sesión de AAM sigue siendo válida, la pasarela la restablece en segundo plano con un 302 al demonio de AAM en lugar de devolver al usuario a una página de login — el usuario no ve nada. El cierre de sesión viaja también en sentido contrario: salir de la pasarela envía una señal de logout a cada backend que recibió una identidad inyectada.
Dónde lo usan los equipos
SSO moderno sobre el portal de intranet existente
Un portal interno que ha confiado en X-Remote-User durante una década sigue leyendo X-Remote-User. El gateway ejecuta SAML/OIDC moderno en el borde, luego inyecta la misma cabecera que siempre vio. Sin despliegue en el backend, sin corte de migración.
Authorization-Bearer frente a microservicios
Un cluster de microservicios internos requiere autenticación con token Bearer pero no quiere ejecutar un flujo de identidad por servicio. El gateway emite un token firmado por solicitud y lo inyecta; cada servicio verifica el token contra las claves del gateway.
Un único login, muchas formas de autenticación en el backend
Un despliegue multi-aplicación incluye una aplicación que requiere Basic Auth, otra que requiere una cabecera personalizada, y otra que requiere una cookie. Un gateway AAM gestiona el login una vez; cada backend obtiene la forma que espera, simultáneamente, con condiciones por ruta.
Propagación de identidad con calidad de auditoría
Los regímenes de cumplimiento que requieren una cadena de identidad clara — «quién estaba autenticado cuando esta solicitud llegó al backend» — obtienen esa cadena producida por el flujo de auditoría del gateway. Los valores de cabecera, las condiciones de inyección y el sujeto autenticado se registran juntos.
Preguntas frecuentes
¿Cómo funciona esto sin cambiar el código del backend?
¿Qué pasa si un usuario envía su propio encabezado X-Auth-User para suplantar otra identidad?
¿Puede el gateway enviar una aserción SAML firmada a un backend que espera una por solicitud?
¿Qué ocurre cuando la sesión del backend expira pero la sesión de AAM sigue siendo válida?
¿Puede un gateway AAM ejecutar diferentes formas de inyección para diferentes backends al mismo tiempo?
SSO moderno al frente, autenticación legacy al fondo
Desplegaremos Backend SSO contra sus aplicaciones reales — preservando sus modelos de confianza existentes, eliminando la credencial de manos del usuario, y produciendo una cadena de identidad con calidad de auditoría para cada solicitud.