SSO con SAML 2.0 en el Sector Financiero: Implementación Enterprise

El sector financiero tiene un problema de identidad estructural: decenas de portales, plataformas internas, aplicaciones de socios comerciales y servicios en la nube, cada uno con su propio sistema de autenticación. La proliferación de credenciales favorece su reutilización y los flujos de recuperación débiles; SSO reduce esa superficie, pero no elimina por sí solo el phishing ni el secuestro de sesión: va con MFA y controles de sesión.

SAML 2.0 y OpenID Connect: cuándo conviene cada uno

OAuth 2.0 delega autorización; OpenID Connect añade autenticación. SAML 2.0 y OIDC están vigentes: SAML sigue siendo frecuente en suites enterprise y federación B2B existente; OIDC suele ser preferible para aplicaciones web y móviles modernas y APIs. SAML 2.0 fue diseñado para la federación de identidad entre organizaciones, con aserciones XML firmadas con certificados X.509 y atributos de usuario complejos, y conserva presencia relevante en entornos enterprise; la elección depende de compatibilidad, patrón de integración, modelo de amenazas y operación.

En cores y plataformas heredadas la federación suele requerir un portal, gateway o capa intermedia; se valida por producto y versión el flujo admitido, la sesión y los atributos disponibles. Ambos pueden requerir componentes de integración; el impacto se mide en la arquitectura concreta.

Arquitectura de una implementación real

En el portal de vales de Intelyvale, sus clientes corporativos entran con la cuenta de su propia empresa: federamos su proveedor de identidad y separamos ese acceso del inicio de sesión local.

Los problemas que nadie menciona

La implementación técnica de SAML es relativamente directa con bibliotecas maduras. Los problemas reales aparecen en la operación real: rotación de certificados (si el IdP rota su certificado sin notificar a los SPs, los usuarios quedan bloqueados; con metadatos, la rotación se automatiza), atributos inconsistentes (diferentes SPs esperan el mismo atributo con nombres diferentes), el mapeo de roles del directorio del cliente a los del sistema, el alta de usuarios en el primer acceso y el cierre de sesión en ecosistemas híbridos.

Las aserciones dependen de condiciones de tiempo (NotBefore / NotOnOrAfter); la tolerancia se define explícitamente, tan reducida como permita la operación, con sincronización de hora monitoreada.

El proveedor de servicio valida de forma estricta firma y cadena de confianza, emisor, audiencia, destino, vigencia, correspondencia con la solicitud y uso único de la aserción, y se protege contra repetición y XML signature wrapping. Aceptar una aserción “firmada” no basta.