Workforce federation
IAM Identity Center, IAM SAML federation, the three AWS Directory Service options, AD trusts, and ABAC with session tags.
Exam tasks: 1.2 (centralized identity, federation with existing identity providers, multi-account access), 4.2 (identity and access in migrated workloads)
The decision: where do your employees' identities already live, and how many AWS accounts do they need to reach? That decides between IAM Identity Center and per-account IAM federation, and which directory service connects them.
This page is about workforce identity (employees and contractors). Customer sign-in for your apps is covered in app authentication.
Choosing an approach
IAM Identity Center
The default answer for workforce access to many accounts. It's enabled in the organization's management account (or run from a delegated administrator member account) in one home Region.
- Identity source: exactly one at a time. The Identity Center directory, Active Directory (through AWS Managed Microsoft AD or AD Connector), or an external SAML 2.0 IdP.
- Permission sets: a template of AWS managed, customer managed or inline policies, plus an optional
permissions boundary and session duration. Assigning a permission set to a group for an account creates an
IAM role named
AWSReservedSSO_...in that account. - Assignments: group + permission set + account. Change the permission set once and Identity Center updates the role in every assigned account.
- SCIM: with an external IdP, SCIM provisions users and groups automatically. Without SCIM, users must exist in Identity Center before they can sign in.
- Access portal and CLI: users get one portal, and
aws configure ssogives the CLI short-term credentials. There are no long-term access keys to rotate. - Beyond AWS accounts: SAML apps, and AWS managed apps such as Amazon Q, QuickSight and Redshift, which can use trusted identity propagation to pass the user's identity to the data layer.
Exam signal
"Hundreds of accounts", "central workforce access", "least operational overhead" and "existing corporate IdP" all point to IAM Identity Center with permission sets. Per-account IAM users, or per-account SAML providers and roles, are the distractors.
Legacy: use IAM Identity Center instead
AWS Single Sign-On (AWS SSO) is the old name of IAM Identity Center. Older material that mentions AWS SSO means the same service.
IAM SAML federation vs Identity Center
| IAM SAML federation | IAM Identity Center | |
|---|---|---|
| Setup | An IAM identity provider and roles in every account | Once, for the whole organization |
| Role mapping | IdP sends a SAML Role attribute listing role ARN and provider ARN pairs | Group assignments to permission sets |
| User provisioning | None. Users exist only in the IdP | SCIM from the IdP, or AD sync |
| Sign-in flow | IdP posts the assertion to the AWS sign-in SAML endpoint, which calls AssumeRoleWithSAML | IdP to Identity Center, then the portal, then a role |
| Fits | One or a few accounts, or tight per-account control the IdP team already owns | Multi-account organizations |
Related STS flows you may see:
AssumeRoleWithWebIdentity: OIDC tokens, for example GitHub Actions or EKS service accounts assuming a role without stored keys.- A custom identity broker that authenticates users itself and calls
AssumeRoleorGetFederationToken. It still works, but it's rarely the best answer now that SAML and Identity Center exist.
AWS Directory Service options
| AWS Managed Microsoft AD | AD Connector | Simple AD | |
|---|---|---|---|
| What it is | Real Windows AD domain controllers run by AWS | A proxy that forwards requests to your on-premises AD | Samba-based AD-compatible directory |
| Where directory data lives | In AWS | Stays on-premises | In AWS |
| Trusts with on-premises AD | Yes: one-way or two-way, forest or external | No, it isn't a domain | No |
| Needs connectivity to on-premises | Only for the trust | Always. If the link fails, sign-in fails | No |
| Domain join EC2, RDS for SQL Server, FSx for Windows | Yes | EC2 and some services | EC2 and some services |
| Identity Center source | Yes | Yes | No |
| MFA | RADIUS | RADIUS, against your on-premises users | No |
| Scale | Standard or Enterprise edition, multi-Region replication on Enterprise | Small or Large | Small or Large, for simple needs |
- Managed Microsoft AD runs two domain controllers in different AZs by default, and you can add more. Use it when AD-aware workloads (SharePoint, SQL Server with Windows auth, FSx for Windows File Server) move to AWS.
- AD Connector caches nothing. It's the right answer when a policy says "no directory data may be stored in the cloud" and users should sign in with their existing AD credentials.
- Simple AD fits a small, standalone directory for Linux and Windows instances. It doesn't support trusts, MFA or Identity Center.
- A Managed Microsoft AD directory can be shared with other accounts in the organization, so workload accounts domain-join to one directory instead of each running their own.
AD Connector for AD-aware apps
AD Connector is not a domain controller. An application that needs LDAP writes, Group Policy in AWS, or a local DC for low latency needs Managed Microsoft AD, or self-managed DCs on EC2.
Trusts with on-premises AD
- A one-way trust in which the AWS domain trusts the on-premises forest lets on-premises users reach AD-aware workloads in AWS, while AWS-side identities get nothing on-premises.
- A two-way trust is needed when AWS-side identities must reach on-premises resources too, and IAM Identity Center requires a two-way trust to read users and groups from the trusted forest.
- The trust needs network connectivity (Direct Connect or VPN), DNS conditional forwarding both ways, and the AD ports open in security groups and firewalls.
ABAC with session tags
Instead of one role per team, tag the session with attributes from the IdP and write policies that compare them with resource tags.
- SAML: the IdP sends
PrincipalTag:CostCenterstyle attributes. The role's trust policy must allowsts:TagSession. - Identity Center: turn on attributes for access control and map IdP or directory attributes to tags.
- Policy: a condition such as
"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"lets one permission set serve every project. - Transitive tags survive role chaining, so a downstream role still sees the original attributes.
ABAC signal
"The number of roles keeps growing as teams are added" or "access should follow a user's department attribute in the IdP" means ABAC with session tags, not more roles or permission sets.
Tags anyone can change
ABAC only holds if principals can't retag resources or pass their own session tags. Restrict ec2:CreateTags,
s3:PutObjectTagging and similar actions, and sts:TagSession, with conditions or SCPs.
Scenarios
Identity Center with SAML for sign-in and SCIM for provisioning handles 150 accounts from one place, and group membership in Entra ID drives access. Per-account SAML providers work but multiply the setup by 150. AD Connector connects to Active Directory domain controllers, not to Entra ID. IAM users add long-term credentials and a sync job to maintain.
Managed Microsoft AD gives the workloads real domain controllers in AWS, and a one-way trust lets on-premises users authenticate to them without copying their accounts. Because the on-premises forest doesn't trust the AWS domain, AWS-side identities get nothing on-premises. A two-way trust breaks that rule, Simple AD can't create trusts, and exporting users into Identity Center copies them and doesn't provide Kerberos domain services.
Further reading
Cross-account access
Role assumption vs resource-based policies, how AWS evaluates a cross-account request, external IDs, and the S3 and KMS patterns the exam loves.
Encryption and key management
KMS key types, key policies and grants, cross-account and multi-Region keys, CloudHSM and external key stores, ACM, and S3 encryption options.