Hub de Identidad para Banca Global

Un banco global no tiene un problema de identidad — tiene uno por región, por adquisición y por línea de negocio. Las divisiones de banca minorista, corporativa, tesorería y patrimonio llegaron cada una con sus propios directorios, sus propias pantallas de inicio de sesión y su propia idea de qué era un “usuario”. El banco necesitaba un único hub de identidad capaz de presentar un frente coherente a empleados y aplicaciones sin forzar a quince jurisdicciones a usar un solo directorio.

El reto

Años de crecimiento dejaron al banco con una proliferación de superficies de autenticación. Algunas divisiones operaban sobre Microsoft Entra ID, otras sobre Google Workspace, y varias unidades heredadas mantenían almacenes de cuentas independientes. Cada nueva aplicación interna significaba otra integración, otro conjunto de credenciales y otra brecha de auditoría. Los equipos de cumplimiento regionales se negaban a ceder sus directorios como sistema de registro, y con razón — la regulación local exigía que siguieran siendo autoritativos.

El mandato era federación sin consolidación: un hub, muchas fuentes de verdad.

Qué desplegó Veripass

Veripass se convirtió en el plano de control que se sitúa por encima de los directorios existentes en lugar de reemplazarlos. Cada región se modeló como un tenant de organización aislado, de modo que los miembros, las políticas y el historial de auditoría de una jurisdicción nunca se filtraran a otra. Las aplicaciones se registraron una sola vez contra la plataforma y luego se otorgaron únicamente a los tenants autorizados a usarlas.

Los proveedores de identidad externos permanecieron exactamente donde estaban. Veripass federó con Entra ID y Google Workspace sobre OIDC, de modo que los empleados siguieron autenticándose contra su directorio de origen. SCIM gestionó el ciclo de vida — las cuentas aprovisionadas, actualizadas y desaprovisionadas aguas arriba fluían automáticamente al hub. SAML cubrió las relying parties más antiguas que no podían hablar OIDC, y las API keys transportaron el tráfico máquina a máquina entre servicios internos para que ningún trabajo automatizado tuviera que tomar prestada una sesión humana.

La autorización pasó del hard-coding de roles por aplicación a un modelo componible construido a partir de claims, capacidades, roles y perfiles de acceso. La política consciente del contexto añadió el riesgo encima: una sesión desde un contexto no reconocido activaba MFA de step-up por correo o TOTP de teléfono, y las operaciones de tesorería más sensibles podían exigir verificación biométrica.

• Federación de organizaciones multi-tenant, un tenant por región
• Federación de Entra ID y Google Workspace sobre OIDC
• Aprovisionamiento SCIM con SAML para relying parties heredadas
• RBAC mediante claims, capacidades, roles y perfiles de acceso
• Acceso consciente del contexto y basado en políticas con MFA de step-up adaptativo
• Trazas de auditoría inmutables con alcance por tenant

Resultado

El banco retiró aproximadamente cuarenta superficies de inicio de sesión independientes en favor de un solo hub. Las nuevas aplicaciones internas ahora se incorporan en días en lugar de trimestres, porque la federación y el aprovisionamiento se resuelven una sola vez en la capa de plataforma. Los directorios regionales siguieron siendo autoritativos, de modo que ningún equipo de cumplimiento tuvo que renunciar a su sistema de registro.

Lo más importante: cada decisión de autenticación y autorización ahora queda en una traza de auditoría inmutable con alcance por tenant. Cuando un regulador pregunta quién accedió a qué, bajo qué política y por qué se exigió un step-up, la respuesta es una consulta y no un proyecto forense. El modelo de federación se mantiene igual ya sea que una región dada opere en la nube, on-premise o híbrido — solo cambia la superficie de despliegue.