Identity Federation on AWS: Workforce SSO with IAM Identity Center

This article is for builders and team leads who need to get their team into AWS without creating IAM users. Whether you're setting up corporate single sign-on (SSO) for the first time or explaining it to your team, this covers the full picture: what federation is, how Identity Center works, and what the setup looks like for both the external IdP and Active Directory paths.

Krishna Kadiyala

Customer Obsessed Technologist

Published Jun 11, 2026

Last modified Jun 13, 2026

Before we dive in, if you are looking for workload identity instead, please see the companion article - Identity Federation on AWS: Workload Identity with OIDC

The problem: IAM users don't scale

When your team is small, creating an AWS Identity and Access Management (IAM) user for each person works fine. But it stops working fast. Passwords to manage in two places. Access keys to rotate. People to offboard from multiple accounts when they leave and inevitably someone forgets one. No connection to the login system your company already uses for email, Slack, and everything else.

Identity federation solves this by letting people log into AWS with their existing corporate credentials. No IAM users created, no passwords stored in AWS, no separate offboarding checklist. When someone leaves the company, their AWS access disappears because it was never separate from their corporate identity.

Here's what that looks like in practice:

1
2
3
4
5
6
7
8
9
  8:00 AM  Open laptop, log in with corporate credentials (one password)
  8:01 AM  Open AWS Console → SSO portal loads → choose your account → you're in
  8:02 AM  In terminal: aws sso login → browser pops briefly → done
  8:03 AM  Open your IDE → "Login with Identity Center" → already authenticated

  Passwords entered today: ONE (your corporate login)
  AWS IAM users created: ZERO
  Static access keys stored anywhere: ZERO

One login, access to everything, all credentials temporary. Here's how it works.

Identity Providers: the single source of truth

Imagine a hotel chain with properties worldwide. There are two ways to handle guest identity:

Without centralized identity: Every hotel has its own guest list. Visit a new city, re-register from scratch. Credit card compromised? Call each hotel individually.

With centralized identity: One guest system. Register once. Every hotel recognizes you. Update your card once, it's updated everywhere. Cancel your membership, every property knows immediately.

An Identity Provider (IdP) is that central system. It stores credentials, group memberships, and attributes, and issues proof of identity to other systems when asked.

Without an IdP, every application manages its own users. AWS has its own, Salesforce has its own, Slack has its own. Separate passwords, separate multi-factor authentication (MFA), separate lifecycle. When someone leaves the company, you disable accounts individually and inevitably miss one.

An IdP flips this: one user database, one password, one MFA enrollment. Applications delegate authentication to the IdP. Disable someone once, they're locked out of everything simultaneously.

This setup, where applications trust an external identity system instead of managing their own users, is called federation.

What federation eliminates:

Without federation	With federation
Create IAM users for every person	IdP is the only user database
Manage passwords in AWS	Users authenticate at IdP with existing credentials
Manually offboard from AWS	Disable in IdP → access revoked everywhere
Static access keys (long-lived)	Temporary credentials (short-lived, auto-issued)
Per-account user management	Centralized access across all accounts

First question when setting up federation: "Who is your IdP?" The answer determines everything else: how authentication works, what attributes you'll map, and where user lifecycle management happens.

The IdPs you'll encounter:

IdP	Where you'll see it
Okta	Mid-market, tech companies, startups that grew up
Microsoft Entra ID (formerly Azure AD; Entra ID throughout)	Enterprise, Microsoft shops with M365
Ping Identity	Finance, healthcare, regulated industries
AWS IAM Identity Center	Has a built-in directory, or connects to any of the above

AWS IAM Identity Center: the service that ties it together

AWS IAM Identity Center (formerly AWS SSO) is the service that makes federation practical for AWS. It centrally manages who gets access to which AWS accounts with what permissions.

Identity Center handles two things that are often confused: authentication (proving who you are, handled by your IdP connection) and authorization (what you can do once logged in, handled by permission sets). When someone says "we need SSO for AWS," they mean the first one. But you need both, and Identity Center manages both.

What Identity Center does

Connects to your identity source / Your external IdP (via SAML), Active Directory (direct), or its own built-in directory
Manages permission sets / Reusable templates defining what IAM policies a user gets per account
Assigns access / Maps users/groups to accounts + permission sets
Provides the SSO portal / A web page listing all your accounts/roles with one-click access
Issues temporary credentials / All access uses short-lived AWS Security Token Service (STS) tokens. No long-term access keys.

Choosing your identity source

Your first decision is where Identity Center gets its users from. You pick one of three options:

Option	When to use
Built-in directory	Small teams, proofs of concept, learning. Identity Center IS the IdP.
External IdP (SAML + SCIM)	Enterprise (most common). Connect Okta/Entra ID/Ping.
Active Directory	On-premises or hybrid environments where AD is the authority.

The built-in directory is self-explanatory: you create users directly in Identity Center. The other two options are different paths to the same destination.

Path A: External IdP (SAML + SCIM)

This is the most common enterprise setup. Your IdP (Okta, Entra ID, Ping) handles authentication via Security Assertion Markup Language (SAML), and System for Cross-domain Identity Management (SCIM) keeps the user directory in sync.

How SAML works (the authentication piece)

SAML 2.0 is an XML-based standard (2005) for exchanging authentication data between systems. It lets your IdP prove a user's identity to AWS without AWS ever seeing their password. The user authenticates at the IdP, the IdP generates a signed document (the assertion) confirming who they are, and AWS trusts that document because it can verify the signature.

For that signature verification to work, the two systems need to trust each other first. Think of a notarized document system. Company A gives Company B a sample of their official letterhead and their notary's signature (one-time setup). Now every time Company A sends a signed document, Company B can verify it: right letterhead? Signature match? Date current? If yes, they trust it. That's how SAML trust works between your IdP and AWS. You exchange metadata and certificates once, and every login after that is verified automatically.

Here's what happens every time someone logs in:

User visits the AWS SSO portal (or AWS Console)
AWS doesn't recognize the user → redirects to your IdP
User authenticates at the IdP (password + MFA)
IdP generates and signs a SAML assertion (a signed XML document proving who the user is)
Assertion is POSTed to AWS (via the user's browser)
AWS validates the signature, creates a session. User is in.

There's also an IdP-initiated flow where the user starts at the IdP portal (Okta dashboard) and chooses "AWS Console." Same result, different starting point.

What's inside a SAML assertion:

Issuer / Who wrote this (the IdP's unique identifier)
Signature / Digital seal proving the document hasn't been tampered with
Subject/NameID / Who this is about (usually the user's email)
Conditions / Validity window (expires in minutes, prevents replay)
AudienceRestriction / Who this is addressed to (only valid for the intended Service Provider)
AttributeStatement / Additional claims (e.g., which IAM role to assume)

Production callout: Certificate rotation is one of the most common causes of SAML outages. When the IdP rotates its signing certificate, the Service Provider must be updated with the new cert before the old one expires.

How SCIM works (the user sync piece)

Connecting an external IdP handles authentication, but Identity Center still needs to know who your users and groups are. That's where SCIM comes in.

Think of SCIM like an HR system that automatically updates every building's access list. Someone gets hired, every system knows. Someone leaves, access gets revoked everywhere. No manual work.

SCIM keeps Identity Center's user list in sync with the external IdP:

User created in Okta → provisioned in Identity Center
User disabled in Okta → disabled in Identity Center
User added to "DevOps" group → group membership syncs → access granted automatically
User removed from group → access removed

This prevents the "former employee still has AWS access" problem. It also means managing access at scale is simple: add users to an IdP group, SCIM syncs the membership, and they automatically get the permissions assigned to that group. No per-user management in AWS.

Production callout: SCIM sync is near-real-time but not instantaneous. If provisioning fails silently, users may exist in the IdP but not Identity Center. Monitor SCIM sync status in your IdP dashboard.

SAML terms you'll see when configuring

You don't need to memorize these now. They'll make sense when you're actually setting up SAML in the console:

Term	Meaning
Assertion	The signed XML document containing identity claims
ACS URL	The endpoint on the Service Provider that receives the SAML response
Entity ID	A globally unique identifier for a SAML participant
Relay State	Where to redirect the user after login (deep-linking)
Metadata XML	Machine-readable document with endpoints and certificates

Path B: Active Directory (direct connection)

If your organization already runs Microsoft Active Directory (on-premises or AWS Managed Microsoft AD), you can skip the SAML + SCIM setup entirely. Identity Center connects to AD directly through AWS Directory Service and reads users and groups from the directory itself.

What's different from the external IdP path:

No SAML configuration. Identity Center authenticates users against AD.
No SCIM provisioning. Users and groups sync natively from AD. You choose which AD groups to make available in Identity Center.
Setup involves connecting your directory (or creating an AD Connector to reach an on-premises AD) and then selecting which groups to sync.

The trade-off: AD as an identity source ties you to AD's structure. You can't mix multiple IdPs, and you lose the flexibility of attribute mapping that SAML provides. But if AD is already your single source of truth and you don't have Okta or Entra ID in the picture, it's the simplest path to get Identity Center running.

When do orgs use this? Companies that are heavily invested in Windows Server and on-premises infrastructure, or those in early stages of cloud migration where AD is still the authority for all user identity. Many of these orgs eventually move to Entra ID (which federates from AD) and switch Identity Center to the external IdP model later.

From here, both paths converge

Regardless of whether you connected an external IdP or Active Directory, everything below works the same: permission sets, account assignments, the SSO portal, and temporary credentials.

Permission sets (the uniform analogy)

Think of a theme park where staff wear different colored uniforms:

🟢 Green = all areas including backstage (Administrator)
🔵 Blue = all areas except backstage (PowerUser)
🟡 Yellow = watch only (ReadOnly)

You design the uniforms once and assign them. Permission sets work the same way: reusable templates assigned to users/groups for specific accounts.

A permission set assignment = WHO + WHERE + WHAT

"The DataEngineering group gets the DataEng permission set on the analytics-prod account."

When a user from that group logs in, they see those accounts in the SSO portal. Choose one, and temporary credentials are issued, scoped to that permission set.

The typical enterprise setup (in order)

AWS Organizations with multiple accounts (dev, staging, prod, etc.)
Enable Identity Center in the management account
Configure SAML federation + SCIM provisioning from Okta/Entra (or connect Active Directory)
Users and groups sync to Identity Center
Create permission sets (AdministratorAccess, ReadOnly, custom)
Assign: groups → accounts → permission sets
Share the SSO portal URL with users

After setup: users log in with corporate credentials, pick an account/role from the portal, and work with temporary credentials. No IAM users, no static keys.

Production callout: Identity Center supports up to 3,500 permission sets across up to 3,000 AWS accounts and applications per instance.

Session duration: User interactive sessions default to 8 hours, configurable from 15 minutes up to 90 days. When they expire, the user re-authenticates. All credentials are temporary, nothing is stored long-term.

Frequently asked questions

"We already have Okta/Entra ID. How much work is Identity Center setup?" If SAML + SCIM is already configured for other integrations, a few hours. From scratch, budget a day for initial config and testing.

"What happens if our IdP goes down?" Existing sessions continue until tokens expire. New logins fail until the IdP recovers. Enterprise IdPs typically offer 99.9%+ SLA targets.

"Can different teams use different IdPs?" Identity Center supports one identity source at a time. For multi-IdP scenarios, consolidate at the IdP layer (e.g., Okta federates from Entra ID for acquired companies).

"What about OIDC? Where does that fit?" OIDC solves a different problem: workload and application identity (GitHub Actions federating into AWS, EKS pods assuming roles, app login flows). It's not part of the workforce SSO setup covered here. I'll cover it in a separate article.

Quick reference glossary

Term	Definition
IdP	Identity Provider: authenticates users and issues identity assertions
SAML	Security Assertion Markup Language. XML-based protocol for exchanging auth data (2005)
SCIM	System for Cross-domain Identity Management. Protocol for syncing user/group data between systems
STS	AWS Security Token Service (AWS STS). Issues temporary credentials
SSO	Single sign-on. One login grants access to multiple systems
Permission Set	Reusable IAM policy template assigned to users for specific accounts
Federation	Trusting an external identity system without creating local accounts

Try it yourself

Never used Identity Center: → Enable it in a test account with the built-in directory. Create a user, create a permission set, assign it, log in via the SSO portal. ~15 minutes. Getting started

Have Identity Center but no external IdP connected: → Configure SAML + SCIM with your Okta or Entra instance. Budget 1-2 hours. Connect to an external IdP

Already federated, want to see what's happening under the hood: → Use your browser's dev tools (Network tab) during an SSO login. Look for a POST to /saml/acs with a form field called SAMLResponse. That's the Base64-encoded assertion. Decode it and read the XML. Makes the protocol tangible.

Cleanup

When you're done testing, remove the resources you created to follow security best practices:

In IAM Identity Center, delete any test users and remove permission set assignments from test accounts
Delete custom permission sets you no longer need
If you configured an external IdP integration for testing, remove the SAML application from your IdP and disable SCIM provisioning

IAM Identity Center itself has no direct charges, but removing unused configurations reduces your attack surface.

Not part of an enterprise yet? Individual developers can sign in to AWS developer tools (like Amazon Q or Kiro) with an AWS Builder ID, a free personal identity that works with any email, no corporate IdP or AWS account required.

Builder Center