Una aplicación y su identity provider no tienen que admitir el mismo protocolo de federación. Una aplicación moderna puede usar OpenID Connect mientras un identity provider empresarial o de un socio sigue usando SAML 2.0. Reescribir uno de los lados solo para igualar los protocolos puede añadir costes, riesgo de migración y dependencias innecesarias.

Un bridge de SAML a OpenID Connect permite que cada lado conserve el protocolo que ya admite. FoxIDs valida la respuesta SAML 2.0 del identity provider externo, aplica los claims y las reglas de seguridad necesarios y emite la respuesta OpenID Connect que espera la aplicación.

Las búsquedas sobre este problema suelen usar expresiones técnicas cortas como SAML a OIDC, OIDC bridge, SAML OIDC bridge, protocol bridge, traducción de protocolos, traducción SAML a OIDC, token translation, identity broker o identity federation broker. La pregunta de arquitectura es la misma: ¿cómo puede una aplicación confiar en un contrato OpenID Connect moderno mientras un identity provider existente, un socio o una aplicación SAML antigua sigue usando el protocolo que ya admite?

No se trata solo de cambiar un formato de token. Un bridge útil debe conservar la identidad prevista, la authentication assurance y el contrato de la aplicación entre estándares con formatos de mensajes, modelos de firma, sesiones y convenciones de claims diferentes.

Cuándo conviene usar protocol bridging

Protocol bridging aporta valor cuando crea una frontera controlada entre sistemas que deben cambiar a ritmos diferentes.

Situaciones habituales:

  • Una nueva aplicación web, móvil o single-page admite OpenID Connect, pero clientes o socios se autentican mediante identity providers SAML 2.0.
  • Aplicaciones SAML 2.0 existentes deben utilizar un identity provider OpenID Connect moderno.
  • Una organización sustituye AD FS u otra plataforma de federación gradualmente, por ejemplo en una migración de AD FS a OpenID Connect, en lugar de cambiar todas las aplicaciones a la vez.
  • Varias aplicaciones deben confiar en una única capa de identidad aunque los identity providers externos usen protocolos distintos.
  • Una migración necesita entornos paralelos de prueba y producción y una ruta de rollback clara.

Si ambos lados ya admiten el mismo protocolo adecuado y pueden conectarse con seguridad, un bridge puede no aportar nada. Úselo cuando reduzca el acoplamiento o permita un cambio gradual, no solo porque sea posible traducir protocolos.

Decida desde el principio si el bridge es una etapa de migración o un componente de arquitectura duradero. Un bridge temporal necesita criterios de salida explícitos para retirar la relación de trust anterior. Un bridge duradero requiere una responsabilidad operativa asignada, supervisión y gestión del ciclo de vida de los certificados en ambos lados.

Elija primero el contrato con la aplicación

El protocolo orientado a la aplicación debe seguir su arquitectura y dirección a largo plazo. Las aplicaciones nuevas suelen usar OpenID Connect para el inicio de sesión y OAuth 2.0 para acceder a API. Las aplicaciones empresariales existentes pueden necesitar seguir con SAML 2.0 hasta su sustitución.

En FoxIDs, la aplicación se registra con el protocolo que consume. El identity provider externo se configura como authentication method con el protocolo que ofrece. FoxIDs se sitúa en la frontera de trust:

SAML 2.0 identity provider → FoxIDs → aplicación OpenID Connect

También es posible la dirección inversa:

OpenID Connect identity provider → FoxIDs → aplicación SAML 2.0

Esta separación permite estandarizar un contrato de aplicación sin exigir que todos los identity providers externos cambien al mismo tiempo.

Dos recorridos de protocol bridging mediante FoxIDs: SAML 2.0 a OpenID Connect y OpenID Connect a SAML 2.0.
FoxIDs permite que la aplicación y el proveedor de identidad utilicen los protocolos que admiten, con FoxIDs como límite de confianza común.

Conserve la semántica de identidad, no solo los nombres de claims

Las SAML assertions y los OpenID Connect tokens representan la identidad de forma distinta. Un mapping directo de nombres rara vez basta en producción.

Defina expresamente el contrato de la aplicación:

  • ¿Qué identificador permanece estable para una persona entre sesiones e identity providers?
  • ¿Qué claims hacen falta para presentación, autorización y auditoría?
  • ¿Cómo se representan, filtran y transforman grupos y roles?
  • ¿En qué issuer y audience confía la aplicación?
  • ¿Qué ocurre si un provider externo omite un claim obligatorio?
  • ¿Pueden correlacionarse con seguridad identidades de varios providers o deben permanecer separadas?

FoxIDs usa JWT claims internamente y puede mapear tipos de claims SAML a los nombres más breves habituales en OpenID Connect. Este claim mapping también puede transformar valores antes de que lleguen a la aplicación. Limite deliberadamente el mapping: emita lo que necesita la aplicación en vez de copiar cada atributo externo en cada token.

Los identificadores estables requieren especial atención. El correo y el nombre de usuario pueden cambiar y suelen ser malas claves primarias. Prefiera un identificador de origen inmutable unido a un issuer claramente definido u otro identificador con ciclo de vida controlado.

Identificadores, claims y contexto de autenticación SAML 2.0 mapeados mediante FoxIDs a tokens OpenID Connect.
El bridge mapea identificadores estables, los claims necesarios y señales de assurance en lugar de copiar todos los atributos del proveedor de identidad externo.

Siga una identidad a través del bridge

Considere un usuario de un socio que inicia sesión mediante un SAML 2.0 identity provider mientras la aplicación usa OpenID Connect:

  • La SAML assertion proporciona un NameID inmutable, una dirección de correo, pertenencia a grupos y un authentication context.
  • FoxIDs valida la firma, el issuer, la audience y la vigencia, y después mapea el identificador de origen estable a sub, los grupos seleccionados a roles de la aplicación y el authentication context aceptado a acr.
  • La aplicación recibe únicamente los OpenID Connect claims acordados y valida FoxIDs como issuer.

La aplicación no necesita lógica SAML específica de cada socio. Al añadir otro identity provider de un socio, sus claims y señales de assurance se normalizan en la frontera de FoxIDs sin cambiar el contrato de token de la aplicación.

Gestione conscientemente la authentication assurance

Un inicio de sesión SAML correcto no indica automáticamente a una aplicación OpenID Connect si se usó MFA ni qué requisitos de assurance se cumplieron.

Defina la relación entre SAML authentication context, OpenID Connect authentication context y los valores acr esperados. Decida si FoxIDs puede aceptar la assurance externa, debe solicitar al identity provider externo un authentication step más fuerte o debe rechazar el inicio cuando falte el context requerido.

El mismo principio se aplica en sentido inverso. Una aplicación SAML 2.0 puede esperar un authentication context concreto aunque el usuario inicie sesión mediante un OpenID Connect identity provider.

No deduzca una authentication fuerte solo por la existencia de una sesión en el identity provider externo. Evalúe el authentication context devuelto según las reglas de assurance configuradas y pruebe tanto los recorridos aceptados como los rechazados.

Distinga las sesiones de inicio de la información de cierre

OpenID Connect y SAML 2.0 usan mecanismos distintos de sesión y cierre. El identity provider externo y la aplicación mantienen sus propias sesiones de inicio. FoxIDs no mantiene entre ellos una tercera sesión de inicio para el usuario; solo conserva la información de sesión necesaria para coordinar el cierre.

Durante el inicio de sesión, la reauthentication y el step-up, FoxIDs envía una authentication request al identity provider externo. FoxIDs no reutiliza la información de cierre como sesión de inicio. El identity provider externo decide, según su propia sesión y los requisitos de la request, si el usuario puede continuar sin interacción o debe volver a autenticarse.

FoxIDs puede utilizar la información de cierre conservada para coordinar el cierre en las relaciones pertinentes. El single logout de extremo a extremo puede funcionar si todos admiten flujos compatibles y el navegador llega a cada endpoint, pero no debe darse por hecho. Pruebe front-channel redirects, sesiones externas caducadas, cierres parciales, varias aplicaciones y cierre iniciado por el provider.

Alinee la duración de la aplicación y los tokens con el comportamiento de sesión esperado del identity provider externo. Finalizar la sesión de la aplicación no termina necesariamente la sesión externa. Los requisitos de reauthentication y step-up deben enviarse en una nueva request y verificarse mediante el authentication context devuelto.

Planifique una migración gradual de SAML a OpenID Connect

Una migración controlada mantiene visibles el bridge, el contrato y la ruta de rollback.

  1. Inventaríe las relaciones actuales. Registre aplicaciones, identity providers, metadatos, certificados, endpoints, claims, identificadores, requisitos MFA, sesiones y responsables.
  2. Defina el contrato objetivo. Decida qué aplicaciones usarán OpenID Connect, qué relaciones SAML 2.0 seguirán y qué claims y señales de assurance cruzarán el bridge.
  3. Configure las dos relaciones de trust. Añada el provider externo como FoxIDs authentication method y la aplicación como FoxIDs application registration.
  4. Pruebe también los fallos. Incluya firmas inválidas, issuer o audience incorrectos, claims ausentes, assertions caducadas, protección contra replay, diferencias de reloj, cierre y rotación de certificados.
  5. Trabaje en un entorno separado. Valide sin cambiar el tráfico de producción y promueva después la configuración revisada de forma controlada.
  6. Mueva primero un grupo limitado. Use una aplicación piloto, un socio o un grupo de usuarios y conserve la ruta anterior hasta demostrar la nueva.
  7. Observe y complete el cut-over. Supervise errores de authentication, diferencias de claims y casos de soporte antes de retirar la antigua relación de trust.

Los FoxIDs tenants pueden contener entornos separados de desarrollo, prueba, migración y producción. Esto facilita la validación paralela y el cut-over gradual, pero no sustituye un plan de rollback ni las pruebas de la aplicación.

Migración en siete etapas desde el inventario y el contrato objetivo hasta la configuración de trust, las pruebas, los entornos controlados, el piloto y el cut-over a producción, con rollback.
Una migración gradual valida las relaciones de confianza y el comportamiento de la aplicación antes del cambio a producción y mantiene disponible el rollback hasta que se comprueba el nuevo recorrido.

Exija evidencias de producción antes del cut-over

El bridge pasa a formar parte de la ruta de authentication y debe operarse como frontera de seguridad. Acuerde las evidencias necesarias para cada decisión de producción en lugar de tratar un inicio de sesión correcto como aceptación.

Área de decisión Evidencias necesarias antes de producción
Trust endpoints Responsables designados, metadatos revisados y restricciones de issuer, audience, recipient y redirect URI
Credentials Claves controladas independientes, algoritmos aceptados, una prueba de rotación de certificados y un responsable de renovación
Contrato de identidad Subject estable, lista de claims permitidos, transformaciones documentadas y comportamiento definido cuando falten claims obligatorios
Authentication assurance Contexts externos aceptados, reglas de MFA adicional y recorridos de rechazo probados
Inicio y cierre Reenvío probado de requests de inicio, reauthentication y step-up, además de cierre, cierre parcial y duraciones pertinentes de tokens y sesiones externas
Fallos y operación Pruebas de mensajes inválidos, caducados y reproducidos, además de registros de auditoría, alertas, responsabilidad de soporte y una decisión de rollback

No copie claves privadas entre sistemas solo para simplificar la migración. Asigne credentials controladas a cada relación de trust y planifique su rotación antes de que caduquen los certificados.

Cómo admite FoxIDs el bridge

FoxIDs implementa protocol bridging mediante su modelo normal de applications y authentication methods. No hay que desplegar un bridge service separado. Una aplicación OpenID Connect puede usar authentication methods SAML 2.0, OpenID Connect o WS-Federation, y una aplicación SAML 2.0 puede usar esas mismas fuentes externas.

Los equipos mantienen un contrato FoxIDs identity provider, mientras identity providers, socios y sistemas antiguos se conectan con los estándares que admiten. FoxIDs también ofrece claim mapping, authentication flows configurables, MFA y entornos separados de prueba y producción.

Consulte la documentación del protocol bridge para conocer el modelo exacto, las authentication methods y las application registrations. Si el trabajo incluye onboarding de aplicaciones, diseño de claims, pruebas o migración gradual, FoxIDs Identity Integration describe la ayuda de implementación del equipo que desarrolla la plataforma.

Conclusión

Un bridge de SAML a OpenID Connect es más útil cuando permite que aplicaciones e identity providers evolucionen de forma independiente sin debilitar el contrato de identidad.

Trate el bridge como una frontera de trust deliberada, no como un traductor de tokens invisible. Cuando el contrato de la aplicación, las reglas de assurance, el comportamiento de inicio y cierre, las evidencias de producción, las responsabilidades y el rollback sean explícitos, FoxIDs proporciona el modelo de implementación basado en estándares para introducir el cambio por etapas controladas.