Multi Cloud Identity Management Framework: A Reference Architecture

A Reference Framework for Cross-Cloud IAM

This is Part 2 of the Multi-Cloud Identity series.

Multi-cloud environments do not naturally share identity. When an organization deploys workloads across AWS, Azure, and Google Cloud, it does not create a single unified system; it creates three isolated silos with incompatible identity models. For architects, the challenge is not integrating tools, but resolving the fundamental mismatch between how each provider structures authority. This framework defines a reference architecture where a centralized Identity Fabric normalizes entitlements, enabling consistent policy enforcement across heterogeneous cloud providers.

The Fragmentation Mechanism

Native cloud IAM systems are designed for single-tenant isolation, not multi-tenant interoperability. AWS IAM uses a resource-based policy model where permissions are attached to roles and resources directly (see AWS IAM User Guide). Azure Entra ID relies on a directory-centric model with role assignments tied to enterprise applications (see Azure Entra ID Documentation). Google Cloud IAM uses a resource hierarchy in which IAM policies bind roles to members at the organization, folder, project, or resource level (see Google Cloud IAM Overview).

These differences create a mechanism failure when attempting cross-cloud operations. Consider a developer named Alice who needs read access to an S3 bucket in AWS and a Blob container in Azure. In AWS, Alice’s identity is an IAM User or Role within the AWS organization. In Azure, she is a Guest User or Member in Entra ID. There is no native protocol for AWS to verify if Alice’s Entra ID token grants her permission to read Azure storage. The cryptographic trust boundaries do not align.

Attempting to sync users manually via CSV imports or simple SCIM connectors creates state drift. If Alice’s role changes in HR, the update may reach Azure first and AWS second, creating a window where she has elevated privileges in one cloud but not the other. This temporal inconsistency is the primary security risk in fragmented IAM.

The Reference Architecture: Three-Layer Model

A structured cross-cloud IAM framework decouples identity from infrastructure. The architecture consists of three distinct layers: the Identity Source, the Identity Fabric, and the Target Systems.

Layer 1: Identity Source (The System of Record)

The Identity Source is the single source of truth for human and service identities. Typically, this is an enterprise directory like Microsoft Entra ID or Okta. It holds the canonical attributes: employee ID, department, job title, and employment status.

Crucially, the Identity Source does not store cloud-specific permissions. It stores who the user is. When an engineer joins the "Security" team, this attribute is updated in the Identity Source. This event triggers a workflow, but it does not directly grant cloud access.

Layer 2: The Identity Fabric (The Normalization Layer)

The Identity Fabric is the core mechanism of cross-cloud IAM. It is a software layer that sits between the Identity Source and the Cloud Providers. Its primary functions are normalization, policy evaluation, and provisioning orchestration.

The Fabric ingests identity attributes from the Source and maps them to a canonical entitlement model. It does not merely replicate users; it translates intent. For example, the attribute department: Security is mapped by the Fabric to specific policies. These policies define what actions are permitted across all clouds.

The Fabric also hosts the Policy Decision Point (PDP). In traditional cloud architectures, the PDP is distributed (each cloud checks its own IAM database). In this framework, the PDP is centralized. When a service account attempts to access a resource, the request is routed through the Fabric, which evaluates the user’s canonical entitlements against the defined policies before forwarding an authorized token to the target cloud.

Layer 3: Target Systems (Cloud Providers)

The Target Systems are the AWS, Azure, and GCP environments. They act as execution nodes. They receive credentials (OIDC tokens, API keys, or SAML assertions) generated or validated by the Fabric. They do not make independent decisions about who can access what; they enforce the permissions granted by the Fabric.

This separation ensures that if a cloud provider’s IAM system is compromised or misconfigured, the attacker still cannot act without valid credentials from the Fabric. The trust boundary shifts from the individual cloud to the Fabric.

Entitlement Normalization: The Canonical Graph

The most complex mechanism in cross-cloud IAM is entitlement normalization. Each cloud uses different granularities for permissions. AWS uses fine-grained actions like s3:GetObject. Azure uses role definitions like Storage Blob Data Reader. GCP uses pre-defined roles like roles/storage.objectViewer (see Google Cloud IAM Roles).

The Fabric resolves this by building a Canonical Entitlement Graph. This is a directed graph where nodes represent actions and edges represent dependencies.

For example, the Fabric defines a canonical action READ_STORAGE_OBJECT. This action is mapped to:

• AWS: s3:GetObject
• Azure: Storage Blob Data Reader (which includes s3:GetObject equivalent)
• GCP: roles/storage.objectViewer

When a policy states ALLOW READ_STORAGE_OBJECT FOR TEAM Security, the Fabric translates this into specific API calls for each cloud. In AWS, it attaches the s3:GetObject policy to the role. In Azure, it assigns the Storage Blob Data Reader role. In GCP, it binds the roles/storage.objectViewer role.

This normalization prevents permission drift. If AWS adds a new required permission for a secure object read, the Fabric updates the mapping for READ_STORAGE_OBJECT, and all affected cloud roles are automatically corrected during the next provisioning cycle.

Operational Mechanics: Just-in-Time Access

Static long-lived credentials are the weakest link in IAM. The reference framework advocates for Just-in-Time (JIT) access provisioning. This mechanism reduces the attack surface by ensuring that permissions exist only when needed (see AWS STS Temporary Security Credentials).

Consider a scenario where Alice needs to debug a production issue in AWS. She requests access via the Fabric’s portal. The Fabric verifies:

1. Alice is in the Security team (Identity Source check).
2. The request is for a specific instance ID (Target System check).
3. The request is within business hours (Policy check).

If approved, the Fabric generates a short-lived OIDC token for that specific AWS role and injects it into Alice’s session. The token expires in 4 hours. When the session ends, the Fabric revokes the role assignment in AWS.

This process is automated via the Fabric’s provisioning engine. The engine listens for policy changes or access requests and executes the necessary API calls to create, update, or delete identities and permissions in the Target Systems. This eliminates the need for manual IAM management and ensures that the state of the Target Systems always reflects the current policy defined in the Fabric.

Conclusion

A multi cloud identity management framework is not solved by buying a tool that connects to multiple clouds. It is solved by implementing a reference architecture that centralizes policy and normalizes entitlements. By separating the Identity Source, the Identity Fabric, and the Target Systems, organizations can manage identity as a unified asset rather than a collection of cloud-specific configurations. This approach reduces complexity, eliminates permission drift, and enforces consistent security postures across all cloud environments.