IAM Identity Center and Enterprise Identity Federation

AWS IAM Identity Center is the workforce identity plane for AWS Organizations — it is where you wire up who your humans are, where their identities actually live (built-in directory, AD Connector, or an external SAML identity provider), how they are provisioned (SCIM push from Okta, Microsoft Entra ID, Google Workspace, or JumpCloud), what they can do (permission sets materialized as IAM roles inside each member AWS account), and increasingly, how their identity is carried forward into analytics engines like Amazon EMR, Amazon Redshift, and AWS Glue through trusted identity propagation. On SAP-C02 the examiner expects you to architect this end-to-end — not just pick the right checkbox — and to pick between raw SAML federation to IAM, IAM Identity Center with external IdP, and IAM Identity Center with its built-in directory based on organizational constraints like regulated industries, existing Active Directory investments, audit requirements, and cross-account access scale.

This guide assumes you already know the CLF-C02 view of AWS access management and goes deep on the Pro-level surface: permission set design with customer-managed policies and permissions boundaries, attribute-based access control using session tags flowing from SAML assertions into IAM condition keys, trusted identity propagation for analytics workloads, delegated administration as a blast-radius control, and the migration path from the legacy AWS SSO experience.

What IAM Identity Center Actually Is (and What It Isn't)

AWS IAM Identity Center — renamed from AWS Single Sign-On in July 2022 — is a regional AWS service that integrates with AWS Organizations to deliver workforce single sign-on, multi-account access, and application access to AWS-managed and external SaaS applications. IAM Identity Center does not replace AWS IAM; it sits on top of AWS IAM, and under the hood each IAM Identity Center permission set becomes an IAM role (with a specific naming prefix AWSReservedSSO_<permission-set-name>_<random-suffix>) inside every AWS account the permission set is assigned to. Users sign in once at the IAM Identity Center AWS access portal, pick an AWS account and permission set, and are handed short-term AWS STS credentials for that IAM role.

What IAM Identity Center is not: it is not a customer identity service (that is Amazon Cognito), it is not an IAM replacement for AWS service principals (Lambda execution roles, EC2 instance profiles still use plain AWS IAM), and it is not a directory service (it has a built-in directory but it is not a substitute for AWS Managed Microsoft AD when you need a real directory for Windows workloads, group policy, or Kerberos).

Why IAM Identity Center matters on SAP-C02

The SAP-C02 exam guide explicitly tests "Design a strategy for access across an organization" (Domain 1 — Design for Organizational Complexity). Nearly every multi-account scenario at Pro level now expects IAM Identity Center as the baseline answer, with SAML-to-IAM federation and standalone IAM user accounts treated as legacy fallbacks. Expect scenarios that combine IAM Identity Center with AWS Organizations SCPs, AWS Control Tower guardrails, and attribute-based access control for multi-tenant or multi-project isolation.

Plain-Language Explanation: IAM Identity Center SSO

Before we drown in SCIM and session tags, here are three mental models from different domains that cover every IAM Identity Center construct you will see on SAP-C02.

Analogy 1: The Corporate Lobby with a Hotel Chain

Imagine your company has offices in 40 cities (your 40 AWS accounts). You don't want every employee to have 40 different keycards and 40 different logins. So you build one master reception desk — the IAM Identity Center access portal. An employee walks up with their corporate ID card (their external IdP credential from Okta or Microsoft Entra ID). The receptionist scans it (SAML assertion), looks up what buildings the employee is allowed to enter today (assignments), and hands them a temporary elevator pass (STS short-term credentials for a permission set role) for the specific office they picked. At 23:59 or whenever the session expires, the elevator pass dies. The employee never gets a permanent key to any specific office.

The HR system pushing new hires and terminations to reception every hour is SCIM. The rules on each elevator pass ("may enter floors 3-5, may not enter floor 12") are the permission set's policies. The "engineers can only enter offices tagged with their project code" is ABAC — the employee's department tag from HR flows to the elevator pass, and each floor's door checks the tag before opening.

Analogy 2: The University Library Card

IAM Identity Center is like a university library card issued by the registrar. The registrar's database is the identity source — either maintained in-house (built-in directory), synced nightly from the admissions office (AD Connector), or fully outsourced to a consortium system (external SAML IdP). The card itself doesn't list every book you can borrow — instead the library has rulebooks by patron category (permission sets): "undergraduates can borrow up to 10 books for 14 days", "grad students can access restricted stacks for 30 days", "faculty can request inter-library loans". When you present your card at the counter, the librarian applies the right rulebook to your checkout.

Trusted identity propagation is what happens when you take a borrowed book to the inter-library loan system — instead of the loan system seeing "a library patron borrowed this", it sees "Professor Chen from Chemistry borrowed this" and can apply Prof. Chen-specific reservation rules. The customer-managed policy inside a permission set is the department-specific rulebook ("the Chemistry department adds these three special rules on top of the university-wide rulebook") that a local librarian (the account admin) can modify without bothering the registrar.

Analogy 3: The Airport Fast-Track Lane

Picture a global airline alliance. Your frequent-flyer status (IAM Identity Center user identity) is issued by your home airline (external IdP like Okta). When you show up at a partner airline's gate (a member AWS account), the gate agent doesn't re-verify you from scratch — they trust the alliance's assertion and give you temporary gate access (permission set role session). Different partner airlines have different lounge access rules based on your status tier — Gold in some airports, Platinum only in others. That tier-to-lounge mapping is the assignment of a permission set to an AWS account.

Meanwhile, delegated administration is the alliance letting a regional hub airline run the alliance desk in its region — the regional hub can issue passes and manage local lounge permissions without bothering the global alliance HQ, but it can't change the alliance's top-level rules. Trusted identity propagation is how your frequent-flyer identity follows you onto a codeshare flight operated by a different airline — the partner's onboard service still knows you personally, not just "some alliance passenger".

Identity Sources — Built-in Directory vs AD Connector vs External SAML IdP

The identity source is the first architectural decision in any IAM Identity Center deployment. You can change it, but switching identity sources deletes all existing users and groups in IAM Identity Center and wipes assignments, which makes it one of the most painful operations on the service — choose carefully.

Built-in directory (Identity Center directory)

The built-in directory stores users and groups inside IAM Identity Center itself, in a managed multi-tenant store. You create users manually in the console or push them via SCIM from a non-SAML source. Authentication happens directly against IAM Identity Center — there is no external IdP in the picture. Password policies, MFA, and session length are all configured inside IAM Identity Center.

Use the built-in directory when:

• You are a small team without an existing corporate IdP.
• You want the fastest path to multi-account SSO without a federation project.
• Compliance requirements prohibit relying on an external IdP.
• You need IAM Identity Center to be the system of record for workforce identities.

Active Directory integration (AWS Managed Microsoft AD or AD Connector)

If your organization runs on-premises Active Directory or AWS Managed Microsoft AD, you can wire IAM Identity Center to that directory. Two variants:

• AWS Managed Microsoft AD — a managed, real AD running inside a VPC; IAM Identity Center federates to it directly. Use when you want to modernize to AWS-hosted AD and still enjoy AD-native features (Kerberos, group policy).
• AD Connector — a lightweight directory gateway that proxies IAM Identity Center requests to an existing on-premises AD over a VPN or AWS Direct Connect. Use when you want to keep AD on-premises as the authoritative source.

Both variants give IAM Identity Center native AD group visibility, so you can assign permission sets to real AD security groups without SCIM. Caveats: AD integration is regional (the directory must be in the same region as the IAM Identity Center instance), and certain features (ABAC with AD attributes, MFA policies) have slightly different configurations.

External SAML 2.0 identity provider

For modern cloud-first organizations with Okta, Microsoft Entra ID (Azure AD), Google Workspace, JumpCloud, Ping Identity, OneLogin, or any other SAML 2.0 IdP, you can connect IAM Identity Center as a SAML service provider. The IdP authenticates the user, emits a SAML assertion, and IAM Identity Center trusts that assertion. User and group provisioning flows via SCIM 2.0 from the IdP to IAM Identity Center — meaning IAM Identity Center keeps a local cached copy of users and groups that is updated whenever the IdP pushes changes.

Choosing the right identity source

SCIM Automatic Provisioning — Okta, Microsoft Entra ID, Google Workspace

Without automatic provisioning, every new hire and every department move requires a manual IAM Identity Center update. SCIM 2.0 (System for Cross-domain Identity Management) solves this by letting the external IdP push user and group changes to IAM Identity Center over a REST API in near real time (typically 40 minutes at most, often a few minutes).

How SCIM works with IAM Identity Center

1. You enable automatic provisioning in the IAM Identity Center console. AWS generates a SCIM endpoint URL and a bearer access token (valid 1 year by default; you must rotate before expiry).
2. In the IdP (Okta, Entra ID, Google Workspace), you configure an IAM Identity Center provisioning app or SCIM integration and paste the endpoint + token.
3. You assign users and groups to the provisioning app in the IdP. Only assigned principals are pushed.
4. The IdP pushes create/update/delete events to IAM Identity Center. IAM Identity Center stores the users and groups in its local cache; it does not store passwords when an external IdP is used (authentication stays at the IdP).

Attribute mapping

By default, SCIM pushes a standard set: userName, displayName, emails, givenName, familyName, active (for deactivation), and group memberships. For ABAC, you also map custom attributes — department, cost center, project code, clearance level, AWS account tag — from the IdP's user profile into IAM Identity Center user attributes, which later flow into SAML assertions and IAM session tags.

SCIM gotchas for SAP-C02

• Nested groups are not universally supported — Okta flattens them by default; Entra ID requires specific configuration. If a SAP-C02 scenario hints at "complex AD group nesting", expect a note that nested groups must be flattened or carefully mapped.
• Group-based assignments are best practice — assign permission sets to SCIM-provisioned groups, not individual users. New hires added to the right IdP group automatically inherit the right AWS account access.
• SCIM token rotation is a 1-year cadence — build a runbook. Expired tokens silently stop provisioning until replaced.
• One-way sync — SCIM is IdP → IAM Identity Center. Changes made directly in IAM Identity Center will be overwritten on the next push.
• Entra ID limits include a SCIM sync interval of 40 minutes minimum; for faster propagation you can trigger an on-demand provisioning cycle from the Entra admin portal.

Permission Sets — AWS-Managed, Custom, Boundary, Session Duration

A permission set is IAM Identity Center's unit of authorization. It is a template stored once in IAM Identity Center and instantiated as a named IAM role in each AWS account the permission set is assigned to. That design is why permission sets are centrally manageable — changing the template updates the IAM role in every account automatically — and why they respect AWS Organizations SCPs, because the materialized IAM role lives inside each member account and is subject to that account's SCP guardrails.

What goes inside a permission set

A permission set can carry up to 10 AWS-managed policies, up to 20 customer-managed policies by name (the policies themselves must exist in each target AWS account), exactly one inline policy (size-limited), one permissions boundary (AWS-managed or customer-managed), and a session duration (between 1 and 12 hours).

The session duration is the maximum lifetime of the STS credentials minted when a user signs in with that permission set. Shorter sessions tighten blast radius; longer sessions reduce re-authentication friction for engineers running long-lived workflows. AWS recommends 1-4 hours for high-privilege permission sets and up to 8-12 hours for low-privilege read-only sets.

AWS-managed vs customer-managed policies inside a permission set

• AWS-managed policies (like AdministratorAccess, ViewOnlyAccess, AmazonS3ReadOnlyAccess) are referenced by ARN and just work in every account. Easiest option, but coarse-grained.
• Inline policy is embedded directly in the permission set and applies to every materialized IAM role across all assigned accounts. Good for org-wide fine-grained rules that don't vary by account.
• Customer-managed policies are the Pro-level trick: the permission set references a policy by name (DevOpsS3WriteAccess), and IAM Identity Center expects a customer-managed policy with that exact name to exist in each target AWS account. This lets account administrators tailor the policy's content per account — a DevOpsS3WriteAccess policy in the production account can be stricter than the same name in dev — while the permission set stays centrally managed.
• Permissions boundary caps the effective permissions of the materialized IAM role. Extremely useful for permission sets that grant IAM permissions: the boundary ensures the role can't create other IAM principals with more permissions than the boundary allows.

Permission set design patterns

Two patterns dominate well-architected IAM Identity Center deployments:

Pattern A: Job-function permission sets. Create permission sets per role (DataEngineer, NetworkAdmin, ReadOnlyAuditor, Developer) and assign them to groups. Inside each permission set, mix AWS-managed policies (for breadth) with an inline policy or customer-managed policy (for org-specific constraints). This scales well for 100+ account estates.

Pattern B: Environment-tier permission sets. Create permission sets per environment (ProdReadOnly, NonProdFullAccess, ProdBreakGlass) assigned across accounts of the right tier. Use with OU-based assignments so a new account in the Prod OU automatically inherits ProdReadOnly for auditors.

Real deployments usually combine both dimensions, yielding a permission-set matrix of (role × tier). Keep the total under ~50 permission sets if you can — audit and review get hard past that.

Materialized IAM role naming and console signals

When a permission set is assigned to an AWS account, IAM Identity Center creates (or reuses) an IAM role named AWSReservedSSO_<permission-set-name>_<random-suffix>. The role trust policy only trusts the IAM Identity Center service principal; you cannot directly assume it from an IAM user. The console signals that a role is SSO-managed by the prefix, and AWS recommends never editing these roles manually — changes are overwritten on the next permission set reconciliation.

Multi-Account Access Assignment — The 3-Tuple Model

An assignment in IAM Identity Center is a 3-tuple: (principal, permission set, AWS account). The principal is an IAM Identity Center user or group; the permission set is one of your defined templates; the AWS account is a specific AWS account within the organization.

Group-based assignments are the rule

For any scale beyond a handful of engineers, you should assign permission sets to IAM Identity Center groups, not individual users. The model scales with the IdP: adding an engineer to the engineering-prod-ro group in Okta, which syncs via SCIM to the same-named group in IAM Identity Center, automatically grants them ProdReadOnly in every production account the group is assigned to — no manual IAM Identity Center operation required.

Assigning across many accounts

You can assign a group-to-permission-set pair to many accounts at once via the console, API, AWS CloudFormation, or Terraform. For AWS Organizations with 50+ accounts, managing assignments in code (Terraform's aws_ssoadmin_account_assignment, or AWS CDK) is essential — the console UX does not scale for hundreds of assignments.

How users switch between accounts

At sign-in, a user lands on the IAM Identity Center access portal and sees a list of AWS accounts and, under each, the permission sets they can use. Picking one federates them into that account with those permissions. For AWS CLI v2, users run aws configure sso once, then aws sso login each session; IAM Identity Center caches short-term credentials in the CLI's SSO cache, and credential_process integration lets SDKs pick them up automatically.

Attribute-Based Access Control (ABAC) — SAML Attributes → Session Tags → IAM Conditions

ABAC is the flagship Pro-level authorization pattern in IAM Identity Center. Instead of writing an IAM policy per combination of user × project × environment, you tag resources with attributes, flow the user's attributes as session tags into the IAM Identity Center sign-in, and write a single IAM policy that compares ${aws:PrincipalTag/Project} against ${aws:ResourceTag/Project}.

The end-to-end ABAC data flow

1. User attribute lives in the IdP (Okta, Entra ID, Google Workspace) or IAM Identity Center directory — for example, department=Finance, project=Atlas, costCenter=CC-42.
2. SCIM provisioning mirrors that attribute into the IAM Identity Center user profile as a user attribute.
3. At sign-in, IAM Identity Center is configured with attributes for access control — a mapping that turns specific user attributes into session tags on the STS session when the permission set role is assumed.
4. Inside the target AWS account, IAM policies (in the permission set or on the resource) reference ${aws:PrincipalTag/<tag-name>} in condition keys to decide access.

Enabling ABAC in IAM Identity Center

1. In the IAM Identity Center console, open Attributes for access control, toggle it on.
2. Declare which user attributes become session tag keys — e.g. Project ← ${user:attribute:project} — using the special mapping syntax.
3. Write permission set policies that reference those session tags:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::data-lake/*",
    "Condition": {
      "StringEquals": {
        "s3:ExistingObjectTag/Project": "${aws:PrincipalTag/Project}"
      }
    }
  }]
}

4. Tag resources (S3 objects, EC2 instances, KMS keys) with the matching attribute values.

The result: one IAM policy serves every project. Adding a new project creates no new IAM policies or permission sets — you just tag the project's resources and add users to the right IdP group.

ABAC vs RBAC on SAP-C03

SAP-C02 scenarios commonly test whether you can recognize when ABAC is better than RBAC. The triggers are:

• Many projects or tenants in one AWS account, each with its own tag.
• New projects spin up frequently — RBAC would require a new IAM role or permission set each time.
• Attribute source of truth already exists in the IdP (project codes in HR system, cost centers in ERP).
• Cross-service enforcement — S3, EC2, KMS, Secrets Manager, Lambda can all evaluate resource tags, so a single policy covers many services.

When those signals are present, pick ABAC with IAM Identity Center session tags over cloning permission sets.

ABAC traps

• Session tag keys are case-sensitive. project and Project are different tags and will not match.
• A session tag key can be at most 128 characters; values up to 256. You can pass up to 50 session tags per session.
• Transitive session tags (tags that propagate when a role chains to another role) must be explicitly marked with TransitiveTagKeys in the assume-role call — IAM Identity Center currently does not mark ABAC tags as transitive automatically.

Customer-Managed Permission Set Policies — Per-Account Flexibility

Customer-managed policies inside a permission set are one of the most important Pro-level knobs and are easy to confuse with AWS-managed or inline policies.

How it works

A permission set references a customer-managed policy by name, not by ARN. For example, a permission set might reference DataPlatformAccess. When IAM Identity Center materializes the role into a target AWS account, it expects a customer-managed IAM policy named DataPlatformAccess to already exist in that account — and it attaches that policy by name.

If the policy doesn't exist in the target account, the assignment fails. This means you must pre-provision the named customer-managed policies in every target account (typically via AWS CloudFormation StackSets or Terraform).

Why this design is powerful

• Per-account tuning: the DataPlatformAccess policy in dev can allow broader DynamoDB access than the same-named policy in prod. The permission set is the same; the per-account policy content differs.
• Respects account boundaries: each account administrator owns the policy content for their account, matching the decentralized ownership of large AWS estates.
• Permissions boundary support: customer-managed boundaries work the same way — reference by name, provision the boundary policy in each account.

When to pick customer-managed over inline

Rule of thumb: if the policy content must vary per account, customer-managed policies win. If the policy is org-wide and identical everywhere, inline in the permission set is simpler and avoids the per-account deployment overhead.

Trusted Identity Propagation (TIP) — EMR, Redshift, Glue, QuickSight

Trusted identity propagation is one of the newest and most-tested IAM Identity Center capabilities on SAP-C02. The traditional problem: when a user runs an Amazon Redshift query or an Amazon EMR Spark job, the downstream service sees a shared IAM role (the execution role, the cluster role), not the real human. That makes per-user authorization inside Redshift, Lake Formation, QuickSight, or Glue almost impossible to wire to the IdP group membership.

TIP changes this by letting AWS analytics services carry the IAM Identity Center user's identity token forward so downstream authorization can check the real user's IAM Identity Center group membership.

How TIP works end-to-end

1. User signs in to IAM Identity Center (via Okta, Entra ID, built-in, etc.) and obtains an OIDC access token in addition to the normal STS credentials.
2. User connects to Amazon Redshift, Amazon EMR Studio, Amazon QuickSight, or AWS Glue using an IAM Identity Center-aware client (Redshift Query Editor v2, EMR Studio, the QuickSight portal).
3. The client passes the IAM Identity Center identity token with the request.
4. The AWS analytics service propagates the identity token to downstream components — Lake Formation, Glue Data Catalog — that enforce authorization on the IAM Identity Center user/group rather than on a shared IAM role.
5. Audit logs (CloudTrail, Redshift audit logs) now record the real human's IAM Identity Center identity for every action.

Services supporting trusted identity propagation

As of 2026 the supported surface includes:

• Amazon Redshift — Redshift Query Editor v2 with IAM Identity Center integration; Redshift can map IAM Identity Center groups to Redshift database roles.
• Amazon EMR Studio — users launch notebooks with their IAM Identity Center identity, and Spark jobs propagate identity to Glue Data Catalog and Lake Formation.
• AWS Glue and AWS Lake Formation — table-level and column-level permissions can be granted to IAM Identity Center users/groups directly, not IAM principals.
• Amazon QuickSight — users sign in via IAM Identity Center and dashboard row/column security keys off IAM Identity Center attributes.
• Amazon S3 Access Grants — a newer S3 capability that issues per-user, per-prefix S3 credentials keyed off IAM Identity Center identity.

TIP prerequisites and gotchas

• IAM Identity Center must be enabled at the AWS Organizations level (not standalone account instance) to propagate identities broadly.
• The client tool must be TIP-aware — older drivers that only use IAM auth do not propagate identity.
• Some services require an AWS IAM Identity Center trusted token issuer configuration when using an external IdP, to map IdP-issued tokens into AWS-recognized identity tokens.
• CloudTrail events for TIP-enabled services include an onBehalfOf field naming the IAM Identity Center user — use this in access reviews.

Delegated Administration for IAM Identity Center

IAM Identity Center is created and primarily managed from the AWS Organizations management account (payer account). But AWS security best practice is to not run day-to-day operations from the management account — its blast radius is too large. Delegated administration lets you nominate a specific member account to run IAM Identity Center operations (create permission sets, make assignments, manage applications) while the management account retains ultimate ownership.

What delegated admin can and cannot do

A delegated administrator can:

• Create, modify, and delete permission sets.
• Create and remove assignments for any account except the AWS Organizations management account itself.
• Manage IAM Identity Center applications and SCIM configuration.
• Configure ABAC attributes.

A delegated administrator cannot:

• Make assignments that grant access to the management account (that remains management-account-only to preserve blast-radius separation).
• Change the identity source or delete the IAM Identity Center instance.
• Enable or disable trusted identity propagation configuration at the org level.

Why delegated admin matters for SAP-C02

Every well-architected multi-account blueprint now puts Identity/SSO operations in a dedicated security or shared-services account (commonly called the "Security" or "Identity" account), not in the management account. AWS Control Tower's default landing zone sets this up automatically. SAP-C02 scenarios that describe "minimize management account activity" or "shared-services account for centralized security tooling" are pointing at delegated administration.

Migration from Legacy AWS SSO

IAM Identity Center is the renamed AWS SSO — same service, new name, and significant feature additions since July 2022. If you find existing AWS SSO documentation, blog posts, or Terraform modules referring to aws_sso constructs, they still work; the service identifier, API endpoints, and IAM prefix remain sso / sso-admin for backward compatibility.

What changed with the rename

• Console name and nav: "AWS Single Sign-On" → "IAM Identity Center".
• URLs: the access portal URL format changed from d-xxxxxxxxxx.awsapps.com/start to .awsapps.com/start (both still work).
• New features introduced post-rename: customer-managed policies in permission sets, trusted identity propagation, delegated administration (for many services), attribute access control enhancements, AWS CLI v2 aws sso login improvements, and account instance vs organization instance.

Account instance vs organization instance

Post-rename IAM Identity Center supports two instance types:

• Organization instance — tied to AWS Organizations, managed from the management account, supports multi-account assignments, trusted identity propagation, delegated admin. The default and the one SAP-C02 assumes.
• Account instance — single-account scope, useful for standalone AWS accounts or for SaaS vendors embedding IAM Identity Center per customer account. Limited feature set (no organization-wide SSO, limited TIP).

Migration steps if you still run raw SAML-to-IAM federation

Legacy shops still using SAML 2.0 identity providers configured directly in AWS IAM (one per account, per-account IAM role trust policies) should plan migration to IAM Identity Center:

1. Enable IAM Identity Center in the management account and configure identity source (external IdP + SCIM recommended).
2. Model existing SAML roles as permission sets. For each legacy SAML IAM role, create a matching permission set with equivalent policies.
3. Assign permission sets to the same accounts and groups that had SAML trust.
4. Flip users over to the IAM Identity Center access portal URL; deprecate the IdP's direct-to-AWS SAML application.
5. After a quiet period, remove the SAML 2.0 identity provider configuration from each account's AWS IAM and remove the legacy IAM roles.

Benefits captured: centralized permission set management (vs per-account IAM role editing), built-in CLI SSO, ABAC, TIP eligibility for analytics, SCIM provisioning instead of just SAML assertions, and delegated administration.

MFA, Session Policies, and Security Hardening

IAM Identity Center inherits strong authentication from its identity source plus its own controls. Key hardening levers on SAP-C02:

• MFA context in permission sets — permission sets can reference aws:MultiFactorAuthPresent in their conditions, forcing elevated permissions to require MFA at sign-in. Combine with an IdP that enforces step-up MFA for privileged permission sets.
• Session duration — tune per permission set. 1-4 hours for admin, 4-8 for engineering, up to 12 for read-only.
• Access portal session — separate from permission set session; controls how long a user's portal session lives before re-auth against the IdP. Default 8 hours.
• Sign-in logs — IAM Identity Center publishes sign-in events to CloudTrail and optionally to CloudWatch Logs via event bus. Mandatory input to your SIEM.
• Access reviews — combine IAM Identity Center assignment APIs with AWS IAM Access Analyzer unused-access findings (which cover materialized SSO roles) to drive quarterly access reviews.

IAM Identity Center Key Numbers and Limits

Common Exam Traps — IAM Identity Center SSO

Trap 1: IAM Identity Center vs raw SAML federation

For multi-account workforce access in 2026, IAM Identity Center is the recommended answer. Raw SAML 2.0 IdP configured directly in each account's AWS IAM is the legacy fallback. If the scenario mentions "existing Okta", "Entra ID", "multiple AWS accounts", or "reduce operational burden of per-account IAM role management", pick IAM Identity Center.

Trap 2: Editing the materialized SSO IAM role

Answer choices suggesting "attach an inline policy directly to the AWSReservedSSO_* IAM role" are wrong — those edits are overwritten on reconciliation. The correct operation is updating the permission set itself.

Trap 3: Customer-managed policy missing in a target account

"Assignment fails with policy not found" usually means the customer-managed policy referenced by name in the permission set was not pre-provisioned in that account. Fix: deploy via AWS CloudFormation StackSets into the right OU.

Trap 4: SCIM pushes one-way

Changes made directly in IAM Identity Center (creating a user manually when an external IdP + SCIM is configured) will be overwritten. The IdP is always the source of truth when SCIM is on.

Trap 5: Session tags are case-sensitive

Project and project do not match. ABAC policies that compare aws:PrincipalTag/Project against aws:ResourceTag/project silently fail because the key casing differs.

Trap 6: Trusted identity propagation requires a TIP-aware client

A JDBC driver from 2020 will not propagate IAM Identity Center identity to Redshift. Scenario fix: upgrade the client (Redshift Query Editor v2, EMR Studio, QuickSight) or the JDBC/ODBC driver version.

Trap 7: Delegated admin cannot assign to the management account

Delegated administration deliberately blocks assignments into the AWS Organizations management account. If a scenario needs workforce access to the management account, those assignments stay in the management account itself.

Trap 8: Changing identity source wipes assignments

Switching from built-in directory to external IdP (or vice versa) drops all users, groups, and assignments in IAM Identity Center. Plan identity source as a one-time decision.

Trap 9: Account instance vs organization instance

Only organization instances of IAM Identity Center support multi-account assignments, trusted identity propagation, and delegated administration. Account instances are scoped to a single AWS account and are not the SAP-C02 default.

Trap 10: AWS SSO is the same service

Documentation or Terraform modules using "AWS SSO" naming still refer to IAM Identity Center. The API namespace remains sso / sso-admin. Distractors that say "AWS SSO is deprecated" are wrong — it was renamed, not retired.

IAM Identity Center vs AWS IAM Roles Anywhere vs Amazon Cognito — Scope Boundary

These three services overlap at the edges. Correct scoping is tested on SAP-C02:

• IAM Identity Center — workforce humans across many AWS accounts, interactive sign-in, permission sets, SSO portal, SCIM from IdP.
• AWS IAM Roles Anywhere — on-premises or non-AWS workloads obtaining short-term AWS credentials via X.509 certificates from your private CA, without long-term access keys.
• Amazon Cognito — customer (end-user) identity for mobile and web apps, sign-up/sign-in flows, user pools and identity pools, tokens swapped for AWS credentials via IAM roles.

One-line scope rule: if the user is an employee logging in to AWS tools, pick IAM Identity Center. If the principal is a server, container, or on-prem workload, pick IAM Roles Anywhere (or instance profiles if it runs in AWS). If the principal is a customer of your app, pick Amazon Cognito.

Practice Scenario Patterns — Mapping to IAM Identity Center

• "40 AWS accounts, 500 engineers in Microsoft Entra ID, central workforce SSO needed." → IAM Identity Center with Entra ID as external SAML IdP + SCIM for auto-provisioning + group-based permission set assignments.
• "Dev and prod accounts should share the same permission set, but S3 access must be broader in dev." → Customer-managed policy referenced by name in the permission set; per-account content deployed via CloudFormation StackSets.
• "Analysts running Redshift queries — row-level security must reflect the real user, CloudTrail must show who ran each query." → IAM Identity Center with trusted identity propagation into Redshift, Redshift roles mapped to IAM Identity Center groups.
• "Security team wants to operate SSO from a dedicated account without using the management account." → Delegated administration of IAM Identity Center to a member account in the Security OU.
• "Many projects in one account, frequent new projects, want to avoid creating new IAM roles per project." → ABAC with session tags flowing from IdP attributes through IAM Identity Center into aws:PrincipalTag conditions.
• "Employee leaves the company — their AWS access across all accounts must be revoked within 15 minutes." → SCIM deprovisioning from the IdP propagating to IAM Identity Center; existing sessions expire at their permission set session duration.
• "Migrating from per-account SAML 2.0 IAM identity provider to modern setup." → Model SAML roles as permission sets, pilot in one OU, cut over, then remove legacy SAML identity providers in each account.
• "Auditor needs quarterly access review across the entire AWS estate." → IAM Identity Center assignment APIs + IAM Access Analyzer unused-access findings on materialized AWSReservedSSO_* roles.

FAQ — IAM Identity Center Top Questions

Q1: When should I use IAM Identity Center instead of raw SAML federation to AWS IAM?

Use IAM Identity Center whenever you have two or more AWS accounts and a workforce that needs consistent sign-in across them. IAM Identity Center centralizes permission management (permission sets vs per-account IAM roles), provides a unified access portal, includes AWS CLI v2 SSO support, enables SCIM provisioning, unlocks trusted identity propagation for analytics, and allows delegated administration. Raw SAML-to-IAM federation still works for one-off cases, but the per-account operational burden (one SAML identity provider configuration and per-account IAM role trust policies for every new account) is exactly what IAM Identity Center was built to eliminate. On SAP-C02, expect IAM Identity Center to be the correct answer in multi-account scenarios.

Q2: How does SCIM automatic provisioning actually work with Okta or Microsoft Entra ID?

You enable automatic provisioning in the IAM Identity Center console, which generates a SCIM endpoint URL and a bearer access token (valid 1 year). You paste these into an IAM Identity Center provisioning app in Okta or an enterprise app with provisioning in Entra ID. You assign the users and groups you want provisioned. The IdP pushes users and groups to IAM Identity Center via SCIM REST calls, typically within minutes. Deactivations and deletions propagate the same way, terminating IAM Identity Center access. Best practice: assign permission sets to SCIM-synced groups, not individual users, so lifecycle is fully managed from the IdP side.

Q3: What's the difference between AWS-managed, customer-managed, and inline policies in a permission set?

AWS-managed policies are referenced by ARN (e.g., arn:aws:iam::aws:policy/ReadOnlyAccess) and work identically in every account — simplest option. Inline policies are embedded in the permission set itself and the exact same content is attached to the materialized IAM role in every assigned account. Customer-managed policies are referenced by name only — the permission set says "attach the policy named DataAccess", and IAM Identity Center expects a customer-managed IAM policy with that exact name to already exist in each target account. Customer-managed policies enable per-account customization: DataAccess in dev and DataAccess in prod can have different content. The tradeoff is you must pre-provision the named policy in every target account (AWS CloudFormation StackSets or Terraform) before assignments work.

Q4: How does attribute-based access control (ABAC) in IAM Identity Center flow end-to-end?

A user attribute (like project=Atlas) is set in your IdP, flows via SCIM to the IAM Identity Center user profile, and is mapped — through IAM Identity Center's "Attributes for access control" feature — to a session tag key on the STS session created at sign-in. Inside the target AWS account, IAM policies in the permission set or on resources reference that session tag with ${aws:PrincipalTag/Project} in condition keys, and compare it against resource tags with ${aws:ResourceTag/Project}. The outcome is that one IAM policy serves arbitrarily many projects: adding a new project just means tagging its resources and adding users to the matching IdP group — no new IAM policy or permission set needed.

Q5: What is trusted identity propagation and why does it matter for analytics?

Trusted identity propagation (TIP) lets AWS analytics services — Amazon Redshift, Amazon EMR, AWS Glue, AWS Lake Formation, Amazon QuickSight, and Amazon S3 Access Grants — carry the IAM Identity Center user's identity token forward so downstream authorization and audit logs see the real human, not the shared IAM role the compute ran under. This unlocks real per-user row-level and column-level security, ties CloudTrail events to specific analysts, and enables consistent governance across analytics pipelines. Without TIP, authorization downstream is based on the cluster or notebook's shared IAM role, which makes per-user policies and audit extremely hard. TIP requires an organization instance of IAM Identity Center and TIP-aware clients (Redshift Query Editor v2, EMR Studio, current driver versions).

Q6: Why is delegated administration a best practice?

Running IAM Identity Center from the AWS Organizations management account concentrates blast radius — the management account is also where billing, org-wide SCPs, and account lifecycle live, and AWS explicitly recommends minimizing its day-to-day use. Delegated administration lets you nominate a member account (typically in a Security or Identity OU) as the operational home for IAM Identity Center: SSO admins can create permission sets and assignments from that account without management-account credentials. Delegated admins cannot assign into the management account itself, preserving an isolation boundary. This pairs naturally with AWS Control Tower landing zones, which stand up a dedicated security account from day one.

Q7: What's the migration path from legacy AWS SSO or raw SAML-to-IAM federation?

IAM Identity Center is the renamed AWS SSO — no migration between them is required; existing AWS SSO configurations became IAM Identity Center configurations automatically at the rename. For organizations still running raw SAML 2.0 identity providers configured directly in each account's AWS IAM (the pre-IAM-Identity-Center pattern): enable IAM Identity Center in the management account, configure the identity source (external IdP + SCIM strongly recommended), model every existing SAML IAM role as a permission set with equivalent policies, assign permission sets to the same groups and accounts, flip users to the IAM Identity Center access portal URL, and after a quiet period remove the legacy per-account SAML identity provider configurations and IAM roles.

Q8: Can IAM Identity Center assign permission sets to an entire AWS Organizations OU automatically?

Not natively — IAM Identity Center assigns permission sets to individual AWS accounts, not OUs. For SAP-C02 Pro-level scenarios that need OU-scoped assignments, the answer is landing-zone automation: AWS Control Tower Account Factory for Terraform (AFT) or a custom Lambda triggered by AWS Organizations events. The automation watches for accounts joining an OU and calls the IAM Identity Center assignment APIs to apply the right permission sets. Keep the automation's own IAM policies tightly scoped, since it has org-wide access-granting powers.

Q9: How do IAM Identity Center session duration, access portal session, and MFA interact?

Three independent timers operate. The access portal session (default 8 hours, configurable) is how long a user's browser session against IAM Identity Center lives before re-authenticating at the IdP. The permission set session duration (1-12 hours, default 1) is how long the STS credentials for a specific account/permission set are valid. MFA enforcement is evaluated by the IdP at each sign-in (or step-up for privileged groups) and can be required at the permission set level via aws:MultiFactorAuthPresent conditions. On SAP-C02, tune permission set duration short for admin-grade sets (1-4h) and longer for read-only (8-12h); keep portal session ≤8h for most workforces.

Q10: What should I pick — IAM Identity Center, AWS IAM Roles Anywhere, or Amazon Cognito?

IAM Identity Center is for workforce humans signing in to AWS across many accounts. AWS IAM Roles Anywhere is for on-premises or non-AWS workloads (servers, containers, build agents) that need short-term AWS credentials via mutual TLS with X.509 certificates from your private CA. Amazon Cognito is for your app's end-user customers — mobile and web apps that sign users up, sign them in via passwords or social identity, and trade those tokens for AWS credentials. The three do not overlap in practice: employee → IAM Identity Center; machine/workload → IAM Roles Anywhere (or instance profile if in AWS); app customer → Amazon Cognito.

Further Reading

• AWS IAM Identity Center User Guide
• Manage your identity source
• Automatic provisioning with SCIM
• Permission sets concepts
• Customer-managed policies in permission sets
• Attributes for access control (ABAC)
• Trusted identity propagation
• Delegated administration
• IAM session tags
• AWS SSO renamed to IAM Identity Center
• AWS SAP-C02 Exam Guide (PDF)