Multi-CloudSecurityadvanced

Identity Federation Patterns

Implement SAML, OIDC, and workload identity federation across AWS, Azure, GCP for zero-credential cross-cloud access.

CloudToolStack Team24 min readPublished Mar 14, 2026

Prerequisites

Understanding of authentication protocols (SAML, OIDC, OAuth)
Familiarity with IAM in at least two cloud providers

Identity Federation Across Clouds

Identity federation allows users to authenticate once with a central identity provider (IdP) and access resources across multiple cloud providers without separate credentials for each. This eliminates credential sprawl, simplifies access management, and provides a single point for enforcing security policies like MFA, conditional access, and session management.

Federation uses industry standards: SAML 2.0 for web-based SSO, OIDC (OpenID Connect) for modern applications and workload identity, and OAuth 2.0 for API authorization. Each cloud provider supports these standards but with different configuration approaches, trust models, and terminology.

This guide covers SAML and OIDC federation patterns, cross-cloud workload identity (machine to machine), centralized identity with Entra ID/Okta/Google Workspace, and Terraform configurations for multi-cloud federation.

SAML vs OIDC

SAML 2.0: XML-based, mature, widely supported for enterprise SSO. Best for web console access and legacy applications. OIDC: JSON/JWT-based, modern, lightweight. Best for APIs, mobile apps, and workload identity federation. When possible, prefer OIDC over SAML for new implementations due to its simplicity and native support for machine-to-machine auth.

SAML Federation to Each Cloud

SAML federation enables your corporate identity provider (Okta, Entra ID, Google Workspace, PingFederate) to authenticate users for cloud console access. Users sign in once at the IdP and are redirected to the cloud console with an assertion that maps them to roles.

AWS SAML Federation

bash

# Create a SAML identity provider in AWS
aws iam create-saml-provider \
  --saml-metadata-document file://okta-metadata.xml \
  --name OktaProvider

# Create a role for federated users
aws iam create-role \
  --role-name FederatedAdminRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:saml-provider/OktaProvider"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }]
  }'

# Attach policies to the role
aws iam attach-role-policy \
  --role-name FederatedAdminRole \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Azure SAML Federation

bash

# Azure uses Entra ID as the native identity provider
# Configure external IdP federation via Entra ID
az ad app create \
  --display-name "AWS Console Access" \
  --identifier-uris "https://signin.aws.amazon.com/saml" \
  --web-redirect-uris "https://signin.aws.amazon.com/saml"

# For Entra ID as IdP to AWS/GCP:
# 1. Create Enterprise Application in Entra ID
# 2. Configure SAML SSO with the cloud provider's ACS URL
# 3. Map user attributes (email, groups, roles)
# 4. Assign users/groups to the application

# Azure CLI to list enterprise applications
az ad sp list --all \
  --query "[?tags[?contains(@, 'WindowsAzureActiveDirectoryIntegratedApp')]].{Name:displayName, AppId:appId}" \
  --output table

GCP SAML Federation

bash

# Create a workforce identity pool (for user federation)
gcloud iam workforce-pools create corporate-pool \
  --location=global \
  --organization=ORG_ID \
  --display-name="Corporate Identity Pool"

# Add a SAML provider to the pool
gcloud iam workforce-pools providers create-saml okta-saml \
  --workforce-pool=corporate-pool \
  --location=global \
  --display-name="Okta SAML" \
  --idp-metadata-path=okta-metadata.xml \
  --attribute-mapping="google.subject=assertion.subject,google.groups=assertion.attributes.groups"

# Grant access to the federated identity
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/corporate-pool/group/admins" \
  --role="roles/editor"

OIDC Workload Identity Federation

Workload identity federation enables services running in one cloud to access resources in another cloud without long-lived credentials. Instead of storing cloud credentials as secrets, the workload exchanges its native identity token for short-lived credentials in the target cloud. This is the most secure pattern for cross-cloud service communication.

GCP Workload Identity Federation from AWS

bash

# GCP: Create a workload identity pool for AWS workloads
gcloud iam workload-identity-pools create aws-pool \
  --location=global \
  --display-name="AWS Workloads"

# Add an AWS provider to the pool
gcloud iam workload-identity-pools providers create-aws aws-provider \
  --location=global \
  --workload-identity-pool=aws-pool \
  --account-id=123456789012 \
  --display-name="AWS Account 123456789012"

# Grant the AWS identity access to GCP resources
gcloud storage buckets add-iam-policy-binding gs://my-data-bucket \
  --member="principalSet://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/aws-pool/attribute.aws_role/arn:aws:sts::123456789012:assumed-role/MyLambdaRole" \
  --role="roles/storage.objectViewer"

AWS OIDC Federation from GCP/GitHub

bash

# AWS: Create an OIDC identity provider for GitHub Actions
aws iam create-open-id-connect-provider \
  --url "https://token.actions.githubusercontent.com" \
  --client-id-list "sts.amazonaws.com" \
  --thumbprint-list "6938fd4d98bab03faadb97b34396831e3780aea1"

# Create a role for GitHub Actions
aws iam create-role \
  --role-name GitHubActionsDeployRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:myorg/myrepo:ref:refs/heads/main"
        }
      }
    }]
  }'

Cross-Cloud Trust Patterns

Pattern	Source	Target	Mechanism
AWS to GCP	AWS IAM Role	GCP Resources	GCP Workload Identity Federation (AWS provider)
GCP to AWS	GCP Service Account	AWS Resources	AWS OIDC provider (Google accounts.google.com)
Azure to AWS	Managed Identity	AWS Resources	AWS OIDC provider (Entra ID)
AWS to Azure	AWS IAM Role	Azure Resources	Entra ID federated credentials
GitHub to Any	GitHub Actions	All clouds	OIDC provider in each cloud
Kubernetes to Any	K8s Service Account	All clouds	OIDC (IRSA, Workload Identity, AAD WI)

Terraform Multi-Cloud Federation

hcl

# GCP Workload Identity Federation from AWS
resource "google_iam_workload_identity_pool" "aws" {
  workload_identity_pool_id = "aws-workloads"
  display_name              = "AWS Workloads"
  project                   = var.project_id
}

resource "google_iam_workload_identity_pool_provider" "aws" {
  workload_identity_pool_id          = google_iam_workload_identity_pool.aws.workload_identity_pool_id
  workload_identity_pool_provider_id = "aws-provider"
  display_name                       = "AWS Account"
  project                            = var.project_id

  aws {
    account_id = var.aws_account_id
  }

  attribute_mapping = {
    "google.subject"     = "assertion.arn"
    "attribute.aws_role" = "assertion.arn"
  }
}

# AWS OIDC provider for Azure Managed Identity
resource "aws_iam_openid_connect_provider" "azure" {
  url             = "https://login.microsoftonline.com/${var.azure_tenant_id}/v2.0"
  client_id_list  = ["api://AzureADTokenExchange"]
  thumbprint_list = [var.azure_thumbprint]
}

resource "aws_iam_role" "azure_federated" {
  name = "AzureFederatedRole"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Federated = aws_iam_openid_connect_provider.azure.arn
      }
      Action = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "${aws_iam_openid_connect_provider.azure.url}:aud" = "api://AzureADTokenExchange"
          "${aws_iam_openid_connect_provider.azure.url}:sub" = var.azure_managed_identity_object_id
        }
      }
    }]
  })
}

Centralized Identity Architecture

The recommended architecture for multi-cloud identity uses a single authoritative IdP (Entra ID, Okta, Google Workspace) that federates to all cloud providers. This provides a single source of truth for identities, centralized MFA enforcement, unified access reviews, and consistent security policies.

Architecture Recommendations

Component	Recommendation
Central IdP	Entra ID, Okta, or Google Workspace (one source of truth)
User federation	SAML for console access, OIDC for API access
Workload federation	OIDC workload identity (no long-lived credentials)
MFA	Enforce at IdP level (applies to all clouds)
Access reviews	Quarterly reviews at IdP, automated deprovisioning
Emergency access	Break-glass accounts per cloud (stored securely)

Never Use Long-Lived Credentials

Workload identity federation eliminates the need for long-lived API keys, access keys, or service account keys. If you are still using static credentials for cross-cloud access, migrate to federated identity immediately. Long-lived credentials are the number one cause of credential leakage incidents in cloud environments.

Multi-Cloud IAM Comparison AWS Cognito Guide

Key Takeaways

1SAML 2.0 is best for web console SSO; OIDC is best for APIs and workload identity.
2Workload identity federation eliminates long-lived credentials for cross-cloud services.
3GCP Workload Identity Federation natively supports AWS, Azure, and GitHub OIDC tokens.
4Centralize identity in a single IdP and federate to all clouds.

Frequently Asked Questions

Should I use SAML or OIDC for cloud federation?

Use OIDC for new implementations. It is simpler, supports machine-to-machine auth, and is the standard for workload identity. Use SAML only for legacy SSO scenarios.

How do I access GCP from an AWS Lambda without credentials?

Use GCP Workload Identity Federation with an AWS provider. The Lambda's IAM role token is exchanged for a short-lived GCP access token. No long-lived credentials needed.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.