Puente SAML 2.0, OpenID Connect y WS-Federation

FoxIDs puede actuar como puente de protocolos entre SAML 2.0, OpenID Connect / OAuth 2.0 y WS-Federation. Esto permite que una aplicación siga usando un protocolo de identidad mientras el identity provider externo o la aplicación partner usa otro.

El puente no es un componente separado que haya que instalar. Es el modelo normal de FoxIDs: los usuarios inician sesión mediante un método de autenticación, y FoxIDs emite la respuesta que requiere el application registration. Cuando ambos lados usan estándares diferentes, FoxIDs realiza la traducción de protocolos, claim mapping, creación de tokens y enrutamiento de inicio de sesión.

Algunos equipos describen esto como protocol translation, traducción SAML a OIDC, token translation, identity broker o federation broker. En FoxIDs, esos términos describen el mismo modelo de configuración, pero el diseño debe seguir revisándose como un límite de identity trust. El resultado importante no son solo mensajes o tokens traducidos, sino un contrato de aplicación, issuer, audience, claims y comportamiento de cierre de sesión coherentes entre los estándares conectados.

Use el puente cuando:

Una aplicación ya admite OpenID Connect y necesita iniciar sesión de usuarios desde un identity provider SAML 2.0 o WS-Federation.
Una aplicación SAML 2.0 o WS-Federation necesita usar un identity provider OpenID Connect.
Una aplicación legacy WS-Federation o SAML 2.0 debe conectarse a una plataforma de identidad OpenID Connect moderna sin cambiar la aplicación.
Varias aplicaciones deben confiar en el mismo entorno FoxIDs aunque usen estándares diferentes.

Federated Identity Management (FIM) conecta identidades entre dominios. Single Sign-On (SSO) permite a los usuarios acceder a aplicaciones sin volver a iniciar sesión. FoxIDs admite ambos, y el puente hace que FIM y SSO funcionen a través de límites de protocolo.

Cómo funciona el puente

OpenID Connect, SAML 2.0 y WS-Federation resuelven muchos de los mismos problemas de identidad, pero sus mensajes, tokens, metadatos, certificados y formatos de claims son diferentes.

OpenID Connect se basa en OAuth 2.0 y se usa habitualmente en aplicaciones web, móviles y basadas en API modernas. Usa JSON Web Tokens (JWT) como identity tokens y access tokens.
SAML 2.0 se basa en XML y se usa ampliamente para SSO enterprise basado en navegador. Usa SAML assertions y firmas XML.
WS-Federation se basa en XML y se usa habitualmente en aplicaciones web enterprise y legacy. Normalmente usa tokens SAML 1.1 o SAML 2.0 en respuestas de inicio de sesión WS-Federation.

FoxIDs conecta estos estándares actuando como parte de confianza en ambos lados de la conexión:

Hacia el identity provider externo, FoxIDs se configura como método de autenticación.
Hacia la aplicación, FoxIDs se configura como application registration.
Internamente, FoxIDs representa claims como JWT claims y mapea entre JWT claims y SAML claims cuando es necesario.
La aplicación recibe la respuesta de protocolo que ya entiende.

No es necesario que los protocolos de entrada y salida sean iguales. Una aplicación OpenID Connect puede usar un método de autenticación SAML 2.0. Una aplicación SAML 2.0 puede usar un método de autenticación OpenID Connect. WS-Federation también puede usarse en cualquiera de los lados.

Configurar un puente

Un puente se configura combinando un método de autenticación con un application registration en el mismo entorno.

Configure el identity provider upstream como método de autenticación:
- Método de autenticación OpenID Connect
- Método de autenticación SAML 2.0
- Método de autenticación WS-Federation
Configure la aplicación como application registration:
- OpenID Connect application registration
- SAML 2.0 application registration
- WS-Federation application registration
En el application registration, seleccione el método de autenticación que debe gestionar el inicio de sesión.
Si hay más de un método de autenticación disponible, la aplicación puede seleccionar uno directamente, o el usuario puede elegir en una página de home realm discovery (HRD).
Revise claim mappings, certificados, metadatos y comportamiento de logout para los estándares usados en cada lado.

La decisión de configuración más importante no es por tanto una opción especial de bridge. Es la asociación entre método de autenticación y application registration.

SAML 2.0 a OpenID Connect

Este puente es habitual cuando una aplicación ya admite OpenID Connect, pero la organización o el identity provider partner solo admite SAML 2.0.

Configure el IdP externo como método de autenticación SAML 2.0. Configure la aplicación como OpenID Connect application registration y seleccione el método de autenticación SAML 2.0.

Cuando la aplicación envía una solicitud de inicio de sesión OpenID Connect, FoxIDs enruta al usuario al IdP SAML 2.0 externo. La respuesta SAML 2.0 se valida, los SAML 2.0 claims se mapean a JWT claims, y FoxIDs devuelve una respuesta OpenID Connect a la aplicación.

Puente SAML 2.0 a OpenID Connect

Lea Bridge de SAML a OIDC para aplicaciones OpenID Connect para obtener orientación sobre arquitectura, diseño de claims, migración y preparación para producción.

OpenID Connect a SAML 2.0

Este puente es útil cuando una aplicación SAML 2.0 debe usar un identity provider OpenID Connect moderno.

Configure el provider externo como método de autenticación OpenID Connect. Configure la aplicación como SAML 2.0 application registration y seleccione el método de autenticación OpenID Connect.

Cuando la aplicación SAML 2.0 envía un SAML 2.0 Authn Request, FoxIDs enruta al usuario al OpenID Provider (OP). La respuesta OpenID Connect se valida, los JWT claims se mapean a SAML 2.0 claims, y FoxIDs devuelve una respuesta SAML 2.0 a la aplicación.

Puente OpenID Connect a SAML 2.0

FoxIDs admite bridging de sign-in, logout y single logout entre SAML 2.0 y OpenID Connect.

Escenarios de puente WS-Federation

WS-Federation funciona con el mismo modelo que los otros estándares. Puede configurarse como método de autenticación cuando el identity provider externo es un WS-Federation Security Token Service (STS), y como application registration cuando la aplicación espera una respuesta de inicio de sesión WS-Federation.

Escenarios típicos de puente WS-Federation incluyen:

IdP WS-Federation a aplicación OpenID Connect.
IdP OpenID Connect a aplicación WS-Federation.
IdP WS-Federation a aplicación SAML 2.0.
IdP SAML 2.0 a aplicación WS-Federation.

Esto es útil para escenarios de reemplazo de AD FS, aplicaciones ASP.NET antiguas, SharePoint, Dynamics y otros sistemas que aún usan WS-Federation, mientras las aplicaciones y API nuevas pueden seguir usando OpenID Connect y OAuth 2.0.

Un entorno, un Identity Provider

Toda la funcionalidad de bridge puede combinarse en el mismo entorno FoxIDs. Por ejemplo, una aplicación OpenID Connect puede admitir inicio de sesión mediante métodos de autenticación SAML 2.0 y OpenID Connect al mismo tiempo.

A menudo es más sencillo hacer que las aplicaciones y API confíen en un único entorno FoxIDs como su Identity Provider (IdP), aunque los usuarios se autentiquen mediante protocolos externos diferentes. En ese modelo:

Las aplicaciones se registran en FoxIDs con el protocolo que ya admiten.
Los identity providers externos se configuran como métodos de autenticación.
FoxIDs realiza traducción de protocolos y claim mapping entre ambos lados.
Los clientes OpenID Connect y las API OAuth 2.0 pueden seguir usando ID tokens y access tokens, incluso cuando el inicio de sesión original vino de SAML 2.0 o WS-Federation.

Este modelo es especialmente útil cuando se moderniza gradualmente un paisaje de aplicaciones. Los sistemas SAML 2.0 y WS-Federation existentes pueden seguir funcionando mientras las nuevas aplicaciones usan OpenID Connect y OAuth 2.0.

Token exchange

Si un usuario inicia sesión en una aplicación SAML 2.0 mediante un IdP SAML 2.0 externo, la aplicación recibe un token SAML 2.0 para ese usuario. En arquitecturas zero trust, las API deben seguir llamándose en el contexto del usuario final.

Use token exchange cuando un token SAML 2.0 deba intercambiarse por un access token OAuth 2.0. El access token resultante puede usarse para llamar a API habilitadas para OAuth 2.0 en el contexto del usuario autenticado.

Asignaciones de reclamaciones

FoxIDs utiliza internamente claims JWT y asigna claims SAML 2.0 a claims JWT. El mismo modelo de asignación de claims SAML/JWT también se utiliza para WS-Federation, ya que los tokens de WS-Federation contienen claims SAML.

De forma predeterminada, se aplican las correspondencias estándar; por ejemplo, sub a http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier y email a http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.

Puede revisar y configurar las asignaciones de reclamaciones en la pestaña Configuración > Asignaciones de reclamaciones del entorno, tal y como se describe en la configuración del entorno. Si no existe ninguna asignación para una reclamación, FoxIDs conserva el nombre original de la reclamación. De este modo, se mantienen las reclamaciones a través del puente, al tiempo que se permiten nombres de reclamaciones más cortos JWT cuando se han configurado las asignaciones.

Asignaciones personalizadas

Las asignaciones personalizadas pertenecen al entorno y emparejan un tipo de reclamación de JWT con un tipo de reclamación SAML. Una asignación personalizada tiene prioridad sobre un valor predeterminado modificable para el mismo tipo de reclamación entrante, pero no puede anular una asignación predeterminada bloqueada.

Cuando la opción Crear automáticamente asignaciones entre los tipos de reclamaciones de JWT y SAML está activada en la configuración del entorno, FoxIDs puede añadir asignaciones personalizadas para los tipos de reclamaciones que aún no se hayan asignado a medida que se procesan. También puede añadir, editar o eliminar asignaciones personalizadas manualmente.

Asignaciones predeterminadas

Las asignaciones predeterminadas de reclamaciones SAML 2.0 y JWT están integradas en FoxIDs y son de solo lectura en Control Client. Las asignaciones predeterminadas bloqueadas se aplican siempre. Las asignaciones predeterminadas modificables solo se utilizan cuando ninguna asignación personalizada tiene prioridad para el tipo de reclamación entrante.