Visión de arquitectura: federar identidades a escala

La identidad federada deja de ser un diagrama y se convierte en un problema operativo en el momento en que tienes más de una aplicación y más de una organización a las que servir. Cada aplicación quiere su propio inicio de sesión. Cada organización quiere sus propios usuarios, sus propias reglas y su propio límite. Veripass existe para mantener intactos esos límites a la vez que presenta un plano de control de identidad único y coherente.

Esta visión recorre cómo se construye ese plano de control y por qué el modelo multi-inquilino es la decisión que lo sostiene todo.

Un plano de control, muchos inquilinos

En el centro de Veripass está el modelo de organizaciones multi-inquilino. Cada organización es un límite de primera clase: sus miembros, políticas, roles e historial de auditoría viven dentro de ese inquilino y nunca se filtran fuera de él. Las aplicaciones se registran en la plataforma y luego se conceden a organizaciones específicas, de modo que la misma aplicación puede servir a decenas de inquilinos sin que ninguno vea los datos de los demás.

Esto es lo que hace que la federación sea manejable a escala. En lugar de levantar una pila de identidad separada por aplicación o por cliente, operas una sola plataforma y expresas a cada cliente como un inquilino.

• Las organizaciones son el límite de aislamiento: usuarios, políticas y trazas de auditoría quedan acotados a ellas.
• Las aplicaciones se registran una vez y se federan en las organizaciones que las necesitan.
• Las identidades pueden ser locales a Veripass o provenir de un proveedor de identidad externo.

Federar proveedores de identidad externos

La mayoría de las empresas no quieren mover a sus usuarios. Ya operan Microsoft Entra ID o Google Workspace, y esperan que sigan siendo la fuente de verdad. Veripass federa con ambos mediante OIDC, así que el usuario se autentica contra su directorio de origen y Veripass consume la aserción resultante para establecer una sesión.

Para el aprovisionamiento, Veripass habla SCIM, de modo que las cuentas se pueden crear, actualizar y desaprovisionar desde el directorio de origen en lugar de gestionarse a mano. SAML y OIDC cubren la superficie de autenticación de entrada; SCIM cubre el ciclo de vida. Juntos permiten que una organización mantenga su directorio existente como sistema de registro mientras Veripass se encarga de la federación entre aplicaciones, las políticas y la auditoría.

El tráfico de máquina a máquina se gestiona aparte mediante claves de API, de modo que los servicios automatizados y las integraciones se autentican sin tomar prestada la sesión de una persona.

La autorización es contextual, no solo basada en roles

Federar quién es un usuario solo resuelve la mitad del problema. La otra mitad es decidir qué puede hacer, y esa decisión tiene que tener en cuenta el contexto. Veripass modela el acceso mediante un esquema en capas de claims, capacidades, roles y perfiles de acceso, lo que permite componer permisos en lugar de programarlos a fuego por cada aplicación.

Encima de eso está la evaluación contextual basada en políticas. El acceso puede depender de la organización, el rol, la aplicación y las condiciones de la petición, y cuando el riesgo sube, la plataforma puede exigir un escalado: MFA adaptativo por correo o TOTP de teléfono, o verificación biométrica con rostro, documento de identidad o huella.

Por qué se sostiene a escala

La arquitectura se mantiene coherente porque los límites duros se trazan una sola vez. Los inquilinos aíslan los datos. La federación mantiene autoritativos los directorios. La autorización en capas mantiene componibles los permisos. Y cada acción relevante aterriza en una traza de auditoría inmutable, de modo que el mismo modelo que escala a muchas aplicaciones y muchas organizaciones también sigue siendo explicable ante un auditor.

Tanto si Veripass corre en la nube, on-premise o en una topología híbrida, el modelo de federación es el mismo: solo cambia la superficie de despliegue.