Whitepaper: Mastering Multi-App, Multi-Org Identity Federation in the Cloud

Identity federation is easy to demo with two applications and one directory. It becomes genuinely hard when you have many applications, many organizations, and a requirement that none of them interfere with each other. This whitepaper sets out the model Veripass uses to keep that scenario manageable in the cloud.

The problem with one-off federation

The default way teams handle multi-application identity is to integrate each application against each directory, one connection at a time. It works for a while. Then the connection count grows with the product of applications and organizations, every integration has its own quirks, and deprovisioning becomes a manual hunt across systems. The audit story fragments because each integration logs differently — if it logs at all.

Multi-application, multi-organization federation done right replaces that mesh of point integrations with a single platform that every application and every organization connects to once.

The Veripass model

Veripass organizes the problem around a multi-tenant control plane:

• Organizations are hard isolation boundaries. Members, policies, roles, and audit history are scoped to a tenant and never cross it.
• Applications register with the platform once and are then federated into the organizations that should have them.
• Directories remain authoritative. Veripass federates with Microsoft Entra ID and Google Workspace over OIDC, and supports SAML and OIDC for inbound authentication, so each organization keeps its existing identity provider as the system of record.
• Provisioning flows over SCIM, so account creation, updates, and — critically — deprovisioning happen from the upstream directory automatically.
• Machine identities authenticate with API keys, keeping service-to-service traffic separate from human sessions.

The result is that adding a new organization does not mean re-integrating every application, and adding a new application does not mean touching every organization. Each connects to the platform, and the platform handles the federation matrix.

Authorization across the matrix

Federation answers who; authorization answers what. Veripass composes access from claims, capabilities, roles, and access profiles, which means permissions are defined once and reused across the matrix rather than re-specified per application.

Layered on top is context-aware, policy-based evaluation. An access decision can depend on the organization, the role, the application, and the conditions of the request. When the risk warrants it, the platform demands a step-up: adaptive MFA over email or phone TOTP, or biometric verification with face, ID document, or fingerprint. This keeps the strict scrutiny focused on high-risk moments while the everyday path stays smooth.

Audit that survives the scale

The reason federation tends to collapse under scale is not authentication — it is accountability. When every integration logs differently, no one can answer “who accessed what, where, and why” across the whole estate.

Veripass writes every meaningful action into an immutable audit trail, scoped to its organization. Because authentication, provisioning, authorization, and step-up all run through one platform, the audit record is uniform and reconstructable rather than scattered across a dozen integrations. That is what lets a multi-application, multi-organization deployment remain explainable to an auditor.

Cloud, with portability

This entire model runs in the cloud, but it is not locked to it. Veripass supports cloud, on-premise, and hybrid deployment, so an organization can keep regulated workloads on-premise while federating the rest, all under the same federation, authorization, and audit model. The deployment surface changes; the architecture does not.

The takeaway is simple: federate once, against a platform built for many applications and many organizations, and let the directories stay authoritative, the permissions stay composable, and the audit trail stay whole.