IAM
Intermediate 16 min read IAM

Federation and SSO

One identity story for humans and machines

Federation maps an external identity provider to cloud roles: SAML for corps, OIDC/OAuth for CI and apps. SSO gives humans one login; workload identity gives machines short-lived tokens. Together they abolish long-lived keys.

federationSSOSAMLOIDCOAuthworkload identityIdP
Prerequisites: Roles and Policies Cloud Account Structure
Before we start

What you will learn

  • Explain SAML and OIDC/OAuth federation
  • Map IdP attributes to cloud roles
  • Use workload identity federation in CI
In 60 seconds

Federation lets an external IdP (Entra ID, Okta, Google) vouch for who you are. SAML/OIDC assertions map to cloud roles (and their permissions). Humans get SSO + MFA; CI gets OIDC without storing keys.

Introduction

What is this?

SAML 2.0 (enterprise IdPs) exchanges an assertion that names attributes (groups, email); the cloud maps them to IAM roles (AWS SSO via IAM Identity Center, Azure role assignment via Entra ID groups, GCP via IAM federation with Google IdP). OIDC/OAuth 2.0 is the modern token flow: subject claims (sub, aud, iss) map to cloud roles — used for both apps and CI (GitHub/GitLab Actions, Azure DevOps). Workload identity federation lets GitHub/GitLab/OIDC providers assume cloud roles directly, issuing ephemeral tokens instead of stored keys.

Motivation

Why do you need it?

  • SSO centralizes onboarding, offboarding and MFA for humans.
  • OIDC in CI removes the single biggest credential leak: repo secrets.
  • Federation lets you keep one directory as source of truth.
  • Auditors love 'no standing keys'.
Think about it

Mental model

Imagine

A passport booth at the border

Think of

Federation

Your home country (IdP) issues a passport (assertion/token) proving identity; the border post (cloud) trusts the passport under a treaty (trust relationship) and grants you a visa sticker (role) valid in a border zone (permissions).

Mechanics

How it works

  • SAML: user signs in at IdP → signed assertion → cloud parses attributes → maps to role → STS/SSO session.
  • OIDC: client requests authorization → id_token (JWT with sub/aud/iss/claims) → cloud validates signature → role attribution.
  • AWS: IAM Identity Center + external IdP → permission sets per account/OU.
  • Azure: Entra ID groups → Azure RBAC/s facsimatent to subscriptions; service principals + OAuth flows.
  • GCP: workload identity federation for AWS/GitHub/other OIDC, and IAM federation to Google accounts.

Federated identity flow.

User / CI
IdP (Entra/Okta/GitHub)
Cloud identity bridge
Role / permission set
Resources
Real world

In production

  • A company uses Entra ID + IAM Identity Center: users log in once, get scoped AWS permissions per environment.
  • A startup's GitHub Actions uses OIDC federation with a token-per-branch to deploy to AWS.
  • An enterprise Saml IDP (Okta) maps Entra groups to Azure RBAC roles on subscriptions.
Guidelines

Best practices

  • Attribute mapping is the policy: keep source-of-truth groups clean in the IdP.
  • Always MFA at the IdP; enforce it via the federation policy too.
  • Pin OIDC subjects in CI (repo, ref, environment) to prevent cross-repo assumption.
  • Rotate and monitor IdP trust config; a leak of the signing cert is catastrophic.
Watch out

Common mistakes

  • Storing cloud keys in CI when OIDC exists (biggest avoidable credential risk).
  • Mapped roles too broad because the IdP group is 'admins'.
  • No session duration limits on federated roles.
  • Trusting any OIDC provider without pinning iss/aud/sub.
Root cause analysis

Common issues

Error
SAML login loops in the browser
Root cause

RelayState or audience mismatch, or clock skew

Fix

Verify IdP app + cloud SP config and NTP on the IdP.

Error
OIDC assumption denied from CI
Root cause

Subject claim doesn't match the trust condition

Fix

Print the actual sub/aud from the token and align the trust condition.

Error
SSO works for some users but not others
Root cause

Group membership missing or attribute mapping wrong

Fix

Check the user's IdP groups against the mapping and re-provision.

When things break

Debugging tips

  • Federation failures read like vertex/claims issues: check the assertion's audience matches the cloud side.
  • Check both sides: IdP app config vs cloud trust policy/claim mapping.
  • For OIDC in CI, echo the resolved subject and compare to the role's trust condition.
  • Time syncing: expired-millis assertions are the classic SAML failure.
Interviews

Interview checkpoint

Practice

Hands-on lab

Model Workload Identity for CI
30 min · intermediate
In progress
Objectives
  • Write an OIDC trust policy for a CI provider
  • Pin subject (repo/branch) claims
  • Validate the token claim mapping

Model Workload Identity for CI

30 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which flow eliminates storing long-lived cloud keys in CI?

2

Federation lets an external IdP be the single source of truth for identity.

Go deeper

Official documentation

AWS — IAM Identity Center
docs
Azure — Microsoft Entra ID SSO
docs
GCP — Workload identity federation
docs