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.
Un objeto de configuración por backend, cinco formas de inyección, coordinadas con el resto del motor de acceso.
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.
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.
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.
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.
Cinco formas de inyección en producción, la disciplina de eliminación de entrada que las hace seguras, más el roadmap para inyecciones de protocolo superior.
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.
Para aplicaciones legacy que se autentican mediante HTTP Basic, el gateway inyecta Authorization: Basic
Para backends que ya hablan tokens Bearer (APIs internas, microservicios, aplicaciones modernas de intranet) AAM inyecta Authorization: Bearer
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.
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.
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.
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.
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.
Las formas de inyección de protocolo superior — delegación restringida Kerberos para backends que requieren un ticket de servicio, NTLM para entornos Windows más antiguos — están en el roadmap. El objeto de configuración y la infraestructura condicional ya los acomodan; el trabajo pendiente es el runtime específico del protocolo.
Los mecanismos que hacen segura la inyección a nivel de cabecera en el borde de acceso.
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.
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.
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.
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.
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.
Un flujo de reautenticación silenciosa que usa un 302 al daemon de AAM para restablecer una sesión de backend sin enviar al usuario de vuelta a una página de login está en el roadmap. La propagación de logout iniciada por AAM — empujar una señal de logout hacia cada backend que recibió una identidad inyectada — también está en el roadmap.
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.
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 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.
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.
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.