Lesson 252 · AWS Learning Path

AWS 252: IAM Identity Center and federation

Anil Jalela · Published Mar 4, 2026 · 13 min read

Why this matters to an architect

A company with fifty AWS accounts should not create fifty copies of every employee or issue permanent access keys. Workforce federation keeps people in a controlled identity source, applies corporate authentication and MFA, maps groups to centrally designed permissions, and gives users temporary AWS sessions.

IAM Identity Center is the AWS workforce-access control plane for AWS accounts and supported applications. It is not a replacement for IAM roles used by EC2, Lambda, containers, or CI/CD workloads. This lesson starts with that human-versus-workload boundary, then follows a person from the identity provider to the final API decision.

Outcomes

By the end, you can:

• distinguish workforce identities, workload identities, federation, provisioning, authentication, and authorization;
• choose an organization instance, account instance, and identity source from requirements;
• explain SAML, SCIM, OIDC/PKCE, permission sets, account assignments, and temporary role sessions;
• design group-based least privilege, MFA, ABAC, delegated administration, and independent break-glass access;
• configure and explain an AWS CLI sso-session profile without copying permanent keys;
• trace a request through SCPs, permission-set policies, boundaries, session tags, and resource policies;
• diagnose sign-in, synchronization, assignment, provisioning, session, and API-denial failures from evidence;
• explain session revocation limits, role-name stability, cost ownership, audit, and cleanup.

History and the problem being solved

Before centralized workforce access, organizations commonly created IAM users in every account or maintained separate SAML roles account by account. That multiplied passwords, keys, role mappings, certificate work, and leaver risk. AWS launched AWS Single Sign-On in 2017 and renamed it AWS IAM Identity Center on July 26, 2022. Older names remain in APIs, CLI commands, ARNs, managed policies, service endpoints, and documentation for compatibility; seeing sso-admin, sso-oidc, or AWSReservedSSO_ does not mean a different product.

The architect's goal is one governed route for people:

employee -> corporate IdP + MFA -> IAM Identity Center access portal
         -> account + permission-set choice -> temporary IAM role session
         -> AWS API -> policy evaluation -> CloudTrail evidence

The identity source proves who the person is. Identity Center records the users/groups needed for assignments. A permission set describes what an assigned person may do in an account. IAM and Organizations still decide whether each request is allowed.

Vocabulary without shortcuts

Select the correct instance and identity source

An organization instance is deployed through the AWS Organizations management account and is the normal choice for centrally managing workforce access across organization accounts and supported applications. It has one primary Region, although current Identity Center capabilities can provide multi-Region access when configured. Record the chosen Region because console/API calls such as sso-admin list-instances are Region-scoped.

An account instance is bound to one account and one Region and supports isolated deployments of selected AWS managed applications. It is not the multi-account permission-set solution. Do not choose it merely because a sandbox has one account today if the target architecture is an organization.

Identity-source options include:

• the built-in Identity Center directory, useful for a small standalone workforce or learning environment;
• an external SAML 2.0 IdP such as Microsoft Entra ID or Okta, usually paired with SCIM provisioning;
• supported Microsoft Active Directory integration through AWS Directory Service.

Changing identity sources is a migration, not a cosmetic toggle. User identifiers, group memberships, assignments, synchronization, MFA ownership, application mappings, and rollback must be tested. Some source changes can remove assignments. Export an inventory and follow the current migration documentation before touching production.

SAML authenticates; SCIM provisions

With an external IdP, the browser is redirected to the IdP. The IdP applies passwordless, MFA, device, location, and risk policy, then sends a signed SAML assertion. Identity Center validates values such as issuer, audience, assertion timing, certificate, and subject mapping. Clock skew, an expired signing certificate, wrong metadata, or a mismatched NameID can stop sign-in.

SAML does not let Identity Center query every user and group. Provision them first, preferably with SCIM v2.0. The IdP uses a sensitive SCIM endpoint and bearer token to create/update users, groups, and memberships. Rotate and protect that token like a credential. Monitor synchronization and token expiry. A successful SAML login does not repair a missing SCIM user, and a successfully synchronized user has not yet proved they can authenticate.

For a joiner, create the person in the authoritative HR/IdP flow, require MFA, provision the user and groups through SCIM, and assign groups to permission sets/accounts. For a mover, change authoritative groups/attributes and verify old and new entitlements. For a leaver, disable the person at the source, synchronize removal, remove assignments, end supported Identity Center sessions, and investigate active role credentials. Existing IAM role sessions can continue until their permission-set duration expires - up to 12 hours - so short privileged sessions and emergency response procedures matter.

Permission sets become account roles

A permission set can contain AWS managed policies, customer managed policy references, an inline policy, a permissions boundary reference, tags, session duration, and relay state. A customer managed policy referenced by name/path must exist with the expected content in every target account; Identity Center does not copy that policy document there.

When assigned to an account, Identity Center provisions an IAM role similar to:

arn:aws:iam::111122223333:role/aws-reserved/sso.amazonaws.com/ap-south-1/
AWSReservedSSO_PlatformReadOnly_a1b2c3d4e5f67890

Do not manually edit this generated role. Update the permission set and reprovision affected accounts. Provisioning can fail because of missing policies, IAM quotas, organization integration, authorization, or control-plane errors; an assignment record alone is not proof that the role is ready.

If all assignments for that permission set are removed from an account, the generated role is deleted. A later assignment can create it with a new unique suffix. Exact role ARNs embedded in EKS access, KMS key policies, or other resource policies can then become stale. Keep at least one controlled assignment where AWS recommends it, maintain an independently created recovery role for critical EKS/KMS recovery, and use the documented aws:PrincipalArn ARN-pattern approach where the service and policy semantics support it. Never weaken a resource policy merely to avoid managing the suffix.

Design assignments for least privilege

Prefer governed groups over direct user assignments for ordinary member-account access. Use job-function permission sets such as DeveloperReadOnly, BillingReadOnly, and PlatformOperator, then add separate short-duration elevation rather than one permanent AdministratorAccess role. Avoid a unique permission set per person and avoid one broad permission set reused for unrelated duties.

The Organizations management account is exceptional. AWS recommends dedicated management-account permission sets and direct user assignments rather than groups unless group administration is exceptionally controlled. Anyone able to modify a privileged IdP group could otherwise grant management-account access.

A request still passes through IAM evaluation:

SAML/MFA -> user/group -> account assignment -> provisioned role
-> permission-set identity policies
-> permissions boundary (if configured)
-> session tags and policy conditions
-> SCP/RCP and resource policy
-> allow or deny

Identity Center does not override an SCP explicit deny, a KMS key-policy requirement, an S3 bucket deny, or a missing dependent action. Use AWS251's complete evaluation model when the portal works but an API fails.

ABAC and trusted attributes

Identity Center can pass selected attributes as session tags. Policies then evaluate keys such as aws:PrincipalTag/Department against resource tags. This can reduce thousands of account-specific assignments:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::company-data/${aws:PrincipalTag/Department}/*"
}

The identity source, attribute mapping, and resource-tagging process are security controls. Normalize values such as Finance versus finance; prevent users from self-asserting privileged tags; define who can change HR attributes and resource tags; and test missing, multi-valued, stale, and malicious values. Identity-store mappings take precedence over matching attributes sent in SAML assertions. ABAC scales only when attribute and tag governance scale with it.

MFA, sessions, and revocation

For the built-in directory, configure Identity Center MFA policy and approved authenticators. With an external IdP, authentication and MFA are generally enforced at that IdP; document assurance requirements and conditional-access ownership. “MFA enabled somewhere” is not evidence that every AWS entry path receives the required assurance.

Separate three clocks:

• the external IdP session;
• the Identity Center user-interactive/access-portal session;
• the account IAM role session configured on the permission set (1 hour default; 1–12 hours).

Ending or disabling the upstream session prevents new access, but already issued IAM role credentials operate independently until expiry unless another applicable control blocks their requests. For privileged access, use the shortest workable duration, alert on unusual use, and have a response path that can apply explicit denies or otherwise contain active credentials.

AWS CLI with temporary credentials

Use AWS CLI v2 and configure a reusable token-provider session:

aws configure sso
aws sso login --profile dev-readonly
aws sts get-caller-identity --profile dev-readonly
aws s3api list-buckets --profile dev-readonly
aws sso logout

An illustrative ~/.aws/config is:

[sso-session company]
sso_start_url = https://example.awsapps.com/start
sso_region = ap-south-1
sso_registration_scopes = sso:account:access

[profile dev-readonly]
sso_session = company
sso_account_id = 111122223333
sso_role_name = DeveloperReadOnly
region = ap-south-1
output = json

Do not publish the real start URL, account ID, cached tokens, or credentials. Starting with CLI 2.22.0, aws sso login uses PKCE by default and the authorization URL must be opened on the same browser-capable device. Use --use-device-code when an approved cross-device device flow is needed. Tokens are cached locally; protect the workstation and avoid copying cache files. aws sso logout removes cached Identity Center access tokens and role credentials from the local cache but does not retroactively invalidate credentials already exported or copied elsewhere.

Delegated administration and separation of duties

The organization instance resides in the management account, but one member account can be registered as delegated administrator. This reduces daily management-account access. The delegated administrator can perform most identity, application, permission-set, and assignment work, but cannot enable/delete Identity Center, register another delegated administrator, manage permission sets provisioned to the management account, or enable/disable management-account access.

Separate at least these powers:

• identity-source and SCIM-token administration;
• IdP group/attribute administration;
• permission-set policy design;
• account assignment and provisioning;
• management-account access approval;
• audit and access review.

Limit writes to Identity Store when an external IdP is authoritative; direct changes can be overwritten and can become a privilege path. Tag permission sets and restrict which administrators may assign which permission sets to which accounts.

Break-glass architecture

Federation has shared dependencies: IdP, DNS, network, certificate, SCIM, Identity Center Region, device, and administrator configuration. Maintain a small, independently authenticated emergency path that does not depend on the failed IdP. A typical design uses tightly protected IAM recovery roles/users only where justified, phishing-resistant hardware MFA, no routine use, vaulted credentials with dual control, explicit alerts, short documented activation, quarterly testing, and post-use credential rotation/review. Root credentials remain separately protected for root-only recovery tasks; they are not daily break glass.

The recovery path must survive the outage it addresses without becoming an unmonitored permanent backdoor. Verify that SCPs, KMS/EKS recovery dependencies, and contact ownership do not make the runbook impossible.

Practical lab

Download the AWS252 workforce-federation pack. It contains:

• IDENTITY_CENTER_DESIGN_WORKBOOK.md for a three-account architecture;
• SUPPLIED_FEDERATION_CASES.md with five evidence-driven failures;
• PERMISSION_SET_AND_ABAC_DESIGN.md for policy and attribute decisions;
• BREAK_GLASS_AND_LIFECYCLE_CHECKLIST.md for resilience and joiner/mover/leaver controls;
• ANSWER_DIRECTIONS.md, opened after completing the cases.

Produce an identity-flow diagram, group-to-account matrix, session table, lifecycle RACI, break-glass sequence, and diagnosis for all five cases. The no-create path is complete certification practice; do not enable Identity Center in an owned organization merely for this lesson.

Read-only inspection

With owner approval, select the Region in which Identity Center is enabled:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity
aws sso-admin list-instances \
  --query 'Instances[].{Instance:InstanceArn,Store:IdentityStoreId,Owner:OwnerAccountId}'
aws sso-admin list-permission-sets --instance-arn REPLACE_ME
aws sso-admin describe-permission-set \
  --instance-arn REPLACE_ME --permission-set-arn REPLACE_ME
aws identitystore list-groups --identity-store-id REPLACE_ME --max-results 20
aws sso-admin list-account-assignments \
  --instance-arn REPLACE_ME --account-id 111122223333 \
  --permission-set-arn REPLACE_ME

Redact account IDs, ARNs, emails, display names, group IDs, start URLs, and business-sensitive names. Listing configuration proves control-plane state, not successful sign-in, role provisioning, effective authorization, or revocation.

Troubleshooting from the correct layer

CloudTrail records administrative API activity and account API calls, but not every browser/IdP event. Correlate IdP audit logs, SCIM provisioning logs, Identity Center/Identity Store administrative events, provisioning status, role session identity, and target-service events on a UTC timeline. Do not claim “CloudTrail proves MFA” unless the relevant event fields and authentication path actually support that conclusion.

Cost, quotas, and safe cleanup

IAM Identity Center itself has no additional service charge. Costs can still arise from AWS Directory Service, external IdP licenses, CloudTrail trails/data-event analysis, CloudWatch logs/alarms, Config, SIEM ingestion, support, and staff operations. Track those owners and verify the current pricing pages before estimating.

Quotas exist for permission sets, assignments, policies, and APIs and can change. Use Service Quotas/current documentation for the intended Region and scale; do not memorize a stale number. Large assignment changes can create provisioning time and API-throttling concerns, so automate with retries, idempotency, and status polling.

The supplied lab creates nothing. In an approved sandbox, remove only course-owned assignments first, verify generated-role/resource-policy dependencies, then remove test users/groups or instance configuration according to the owner plan. Preserve redacted evidence. Never switch a production identity source or delete the final assignment behind a critical exact role ARN as “cleanup.”

Knowledge check

1. Why can SAML sign-in succeed while the user still has no account access?
2. What lifecycle job does SCIM perform, and why is its bearer token sensitive?
3. Why is an account instance not the normal multi-account workforce design?
4. How does a permission set become effective in a target account?
5. What can change when the last account assignment is removed and later recreated?
6. Why can a disabled user retain working AWS API credentials temporarily?
7. Where is MFA owned for built-in versus external identity sources?
8. How do Identity Center attributes participate in ABAC, and which teams must govern them?
9. What can a delegated administrator not do?
10. Why must break-glass access be both independent and heavily monitored?
11. Why can the portal show a role while an S3 or KMS request remains denied?
12. What does aws sso logout remove, and what can it not claw back?

Lesson acceptance

Pass requires: correct protocol and instance choices; complete group/account/permission matrix; least-privilege and management-account treatment; permission-set provisioning and role-suffix analysis; ABAC source/tag governance; separate IdP, portal, and role-session clocks; all five supplied diagnoses with evidence; joiner/mover/leaver ownership; tested independent break-glass design; CLI profile explanation; cost/logging owners; and no-create proof or verified cleanup. A screenshot of the access portal alone is not a pass.

Official sources

• What is IAM Identity Center?
• Organization and account instances
• External identity providers
• SAML and SCIM federation
• Permission sets
• Referencing generated permission-set roles safely
• Attributes for access control
• Identity Center authentication sessions
• Delegated administration
• AWS CLI Identity Center authentication