Cloud Identity Federation — SSO, SAML & OIDC Integration Guide

In this tutorial, you'll learn about Cloud Identity Federation. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

Cloud identity federation lets users authenticate with existing corporate credentials to access AWS, Azure, and GCP resources, eliminating the need for separate cloud usernames and passwords through SAML 2.0 and OIDC protocols.

What You Will Learn

How to configure single sign-on across all three clouds, set up SAML trusts between your IdP and each cloud provider, and map federated users to cloud IAM roles.

Why It Matters

Managing separate IAM users for every cloud account does not scale. Federation centralizes identity management, enforces corporate password policies, and ensures that when an employee leaves, all cloud access is revoked from one place.

Real-World Use

DodaTech uses Azure AD as its identity provider. Employees access AWS via IAM Identity Center using their corporate credentials. When a developer leaves, the IT team deactivates the Azure AD account, and all clouds automatically revoke access within minutes.

Federation Flow

sequenceDiagram
  participant User
  participant IdP as Identity Provider (Okta/Azure AD)
  participant Cloud as Cloud Provider (AWS/Azure/GCP)
  
  User->>IdP: 1. Request cloud access
  IdP->>User: 2. Authenticate with corporate credentials
  User->>IdP: 3. Submit credentials
  IdP->>User: 4. SAML assertion / OIDC token
  User->>Cloud: 5. Present assertion
  Cloud->>Cloud: 6. Validate assertion & map to IAM role
  Cloud->>User: 7. Temporary credentials granted

AWS IAM Identity Center

IAM Identity Center (formerly AWS SSO) connects to any SAML 2.0 or OIDC identity provider.

# Enable IAM Identity Center
aws sso-admin create-instance \
  --name "DodaTech Identity Center"

# Create a permission set for developers
aws sso-admin create-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-1234567890 \
  --name "DeveloperAccess" \
  --session-duration PT8H

# Attach a managed policy to the permission set
aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-1234567890 \
  --permission-set-arn arn:aws:sso:::permissionSet/ps-1234567890 \
  --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

# List permission sets
aws sso-admin list-permission-sets \
  --instance-arn arn:aws:sso:::instance/ssoins-1234567890
# Output:
# {
#   "PermissionSets": [
#     "arn:aws:sso:::permissionSet/ps-1234567890",
#     "arn:aws:sso:::permissionSet/ps-0987654321]
#   ]
# }

Azure AD SAML Federation

Azure AD can act as the identity provider or federate with an external IdP.

# Add a SaaS application for AWS in Azure AD
az ad sp create --application-id 12345678-1234-1234-1234-123456789012

# Configure SAML single sign-on
az ad sp update \
  --id 12345678-1234-1234-1234-123456789012 \
  --set preferredSingleSignOnMode=saml

# Create a conditional access policy requiring MFA for cloud access
az identity conditional-access policy create \
  --name "Require MFA for Cloud" \
  --conditions '{"applications":{"includeApplications":["797f4846-ba77-4d83-b0ec-123456789012"]}}' \
  --grant-controls '{"builtInControls":["mfa"],"operator":"OR"}'

az identity conditional-access policy list \
  --query "[].{Name:displayName, State:state}" \
  --output table
# Output:
# Name                    State
# Require MFA for Cloud   enabled

GCP Workforce Identity Federation

GCP supports federation from any OIDC or SAML identity provider through Workforce Identity Federation.

# Create a workforce identity pool
gcloud iam workforce-pools create \
  dodatech-pool \
  --location global \
  --display-name "DodaTech Workforce Pool" \
  --description "Corporate identity pool"

# Configure an OIDC provider (Okta, Azure AD, etc.)
gcloud iam workforce-pools providers create-oidc \
  dodatech-oidc \
  --location global \
  --workforce-pool dodatech-pool \
  --display-name "Azure AD OIDC" \
  --issuer-uri https://login.microsoftonline.com/my-tenant-id/v2.0 \
  --client-id my-client-id \
  --client-secret my-client-secret \
  --attribute-mapping "google.subject=assertion.sub"

# Map federated users to cloud roles
gcloud iam service-accounts add-iam-policy-binding \
  my-sa@my-project.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "principalSet://iam.googleapis.com/projects/my-project/locations/global/workforcePools/dodatech-pool/attribute.email/dev@dodatech.com"

SAML vs OIDC

SAML uses XML assertions and is common in enterprise environments. OIDC uses JSON tokens and is preferred for modern applications. Both are supported by all three clouds.

Common Mistakes

1. Attribute mapping mismatches: If the IdP sends "email" but the cloud expects "mail", federation fails. Verify attribute mappings before rolling out.
2. Expired SAML certificates: SAML signing certificates expire. Rotate them before expiry to avoid federation outages.
3. Overly broad role mappings: Mapping all federated users to a single admin role violates Least Privilege. Use group-based mapping with scoped permissions.
4. No session duration limits: Long session durations increase the window for token theft. Set session limits of 4-8 hours.
5. Ignoring federation for CLI access: Developers often need CLI access via federation. Configure AWS CLI with IAM Identity Center or GCP with workload federation.

Practice Questions

1. What is the difference between SAML 2.0 and OIDC?
2. How does AWS IAM Identity Center map federated users to permissions?
3. What is GCP Workforce Identity Federation?
4. Why should cloud access use group membership rather than individual user mapping?
5. How can you revoke federated user access across all clouds simultaneously?

Challenge

Set up identity federation for a Multi-Cloud environment. Use Azure AD as the identity provider. Configure AWS IAM Identity Center for AWS accounts, Azure AD with conditional access for Azure, and GCP Workforce Identity Federation for GCP projects. Create three groups (admin, developer, viewer) with appropriate permissions in each cloud. Test the federation by authenticating with corporate credentials and accessing cloud resources.

FAQ