Puente SAML 2.0 / OpenID Connect

Por defecto, FoxIDs es un puente entre SAML 2.0 y OpenID Connect / OAuth 2.0 sin configuración adicional.

La gestión de identidad federada (FIM) se centra en vincular identidades entre dominios, mientras que el inicio de sesión único (SSO) simplifica el acceso entre aplicaciones. FoxIDs admite FIM y SSO, y el puente los habilita entre SAML 2.0 y OpenID Connect.

OpenID Connect (OIDC) y SAML 2.0 son protocolos ampliamente usados para la federación de identidad, el inicio de sesión único (SSO) y la autenticación de usuarios. Sin embargo, son fundamentalmente diferentes en estructura y diseño. A veces, necesita tender un puente o integrar estos protocolos, por ejemplo para permitir que una aplicación compatible con OpenID Connect funcione con un proveedor de identidad (IdP) que solo admite SAML 2.0.

Diferencias clave entre los dos tipos de protocolos:

• OIDC: construida sobre OAuth 2.0, es un protocolo moderno diseñado para aplicaciones web y móviles con API RESTful. Usa JSON Web Tokens (JWT) para tokens de identidad y de acceso.
• SAML 2.0: basado en XML y centrado en escenarios SSO basados en navegador, a menudo usado en entornos empresariales. Usa aserciones / tokens basados en XML.

Para conectar un sistema OpenID Connect con un sistema SAML 2.0, necesita una capa de traducción o puente de protocolo. Esto puede lograrse usando un intermediario que actúe como Proveedor OpenID Connect (OP) y Proveedor de Servicios SAML (SP), o viceversa.

Si configura un método de autenticación SAML 2.0 hacia un proveedor de identidad (IdP) externo y conecta su aplicación como una aplicación OpenID Connect donde selecciona el método de autenticación SAML 2.0. Una solicitud de inicio de sesión de su aplicación se enruta como una solicitud de inicio de sesión SAML 2.0 externa. La respuesta de inicio de sesión SAML 2.0 se asigna posteriormente a una respuesta OpenID Connect para su aplicación. Las reclamaciones SAML 2.0 se convierten automáticamente en reclamaciones JWT (OAuth 2.0).

Lo contrario también es posible iniciando la solicitud de inicio de sesión desde un registro de aplicación SAML 2.0 y enrutándola a un proveedor OpenID (OP) externo configurado como método de autenticación OpenID Connect. Luego, la respuesta se convierte en una respuesta SAML 2.0.

FoxIDs admite el puente para inicio de sesión, cierre de sesión y single logout entre SAML 2.0 y OpenID Connect.

Un entorno - un proveedor de identidad

Toda la funcionalidad de puente puede combinarse en el mismo entorno. Permite que una aplicación OpenID Connect admita el inicio de sesión mediante un método de autenticación SAML 2.0 u OpenID Connect al mismo tiempo. La aplicación OpenID Connect puede seleccionar el método de autenticación de forma programática o permitir que el usuario seleccione en una página de home realm discovery (HRD).

Se recomienda tener una infraestructura de aplicaciones con clientes OpenID Connect habilitados y API OAuth 2.0 habilitadas. Donde todas las aplicaciones (clientes y API) confíen en el mismo proveedor de identidad (IdP) - un IdP equivale a un entorno FoxIDs. Al utilizar la funcionalidad de puente en FoxIDs, los tokens SAML 2.0 se asignan a tokens de ID y tokens de acceso que pueden usarse para autenticar aplicaciones OpenID Connect y llamar a API existentes.

Intercambio de tokens

Si un usuario obtiene acceso a una aplicación SAML 2.0 después de un inicio de sesión exitoso con un proveedor de identidad (IdP) SAML 2.0 externo, el usuario obtiene acceso a la aplicación SAML 2.0 en el contexto del propio usuario. Con zero trust (nunca confiar, siempre verificar) necesitará llamar a sus API en el contexto del usuario. Esto es posible usando el intercambio de tokens donde el token SAML 2.0 puede intercambiarse por un token de acceso con la identidad del usuario final. Posteriormente, su API OAuth 2.0 puede ser llamada en el contexto del usuario.

Mapeos de reclamaciones

FoxIDs usa reclamaciones JWT internamente y mapea reclamaciones SAML 2.0 a reclamaciones JWT. De forma predeterminada, se mapea un conjunto de reclamaciones JWT estándar a SAML 2.0 como: sub a http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier, email a http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, etc. Puede agregar mapeos adicionales de reclamaciones JWT a SAML 2.0.
Si no existe mapeo para una reclamación concreta, se conserva el nombre largo de la reclamación SAML 2.0 de las reclamaciones recibidas en un token SAML 2.0 en lugar de un nombre de reclamación JWT equivalente más corto. Lo mismo aplica en la dirección opuesta.