---
title: AWS IAM Identity Center: Workforce SSO and Identity Propagation in Production
description: AWS IAM Identity Center is the AWS-native workforce SSO and identity-propagation service. This guide covers federation from Okta / Microsoft Entra ID, permission-set design, attribute-based access control (ABAC), identity propagation to Q Business / Redshift / QuickSight / S3 Access Grants, and the migration off long-lived IAM users.
url: https://www.factualminds.com/blog/aws-iam-identity-center-workforce-sso-identity-propagation/
datePublished: 2026-04-28T00:00:00.000Z
dateModified: 2026-04-29T00:00:00.000Z
author: Palaniappan P
category: Security & Compliance
tags: iam, iam-identity-center, sso, federation, identity-propagation, access-control, aws
---

# AWS IAM Identity Center: Workforce SSO and Identity Propagation in Production

> AWS IAM Identity Center is the AWS-native workforce SSO and identity-propagation service. This guide covers federation from Okta / Microsoft Entra ID, permission-set design, attribute-based access control (ABAC), identity propagation to Q Business / Redshift / QuickSight / S3 Access Grants, and the migration off long-lived IAM users.

AWS IAM Identity Center is the AWS-native **workforce identity** service. It centralizes federation from Okta, Microsoft Entra ID, Google Workspace, or its own directory; provisions AWS account access through reusable permission sets; and — critically since 2023-2025 — **propagates the workforce identity** through to identity-aware AWS services so audit logs, row-level security, and per-user data-lake access work against the actual human, not a service role.

This guide is for security architects, platform engineers, and IT teams responsible for AWS access. It covers federation setup, permission-set design, attribute-based access control (ABAC) at AWS Organization scale, identity propagation into Q Business / Redshift / QuickSight / S3 Access Grants, and the migration playbook off long-lived IAM users.

> **Need help replacing IAM users with Identity Center across an Organization?** FactualMinds runs IAM modernization engagements alongside Control Tower, ABAC tag governance, and the propagation rollout. [See our cloud security service](/services/aws-cloud-security/) or [talk to our team](/contact-us/).

## Why Identity Center is the workforce-identity baseline

The "long-lived IAM user with an access key" pattern is the most common AWS security finding in 2026 audits. The reasons:

- Long-lived credentials accumulate. People change roles, leave the company, share keys with contractors. The keys outlive the access need.
- IAM users do not federate. There is no clean way to enforce MFA, password rotation, or termination-time revocation through your existing IdP.
- Audit logs show the IAM user. There is no propagated human identity downstream — Redshift queries appear under the BI tool's service role, S3 access shows the application role, GuardDuty findings are anonymous.
- Compliance frameworks demand identity provenance. SOC 2 CC6.1, HIPAA §164.312(d) "person or entity authentication", PCI DSS Requirement 8 "identify users", DORA Article 9, ISO 27001:2022 A.5.16 — all expect the audit trail to identify who, not what.

Identity Center fixes all four. The IdP owns the workforce-identity lifecycle (joiners, movers, leavers); Identity Center issues short-lived AWS credentials on every session; session-tagged identity propagates through to data-aware services so audit logs show the human; deprovisioning is automatic on IdP departure.

## Architecture overview

Identity Center components:

- **Instance** — your AWS Organization-level Identity Center deployment. One per Organization; can be account-scoped (the AWS Organizations "delegated admin" pattern) or Organization-wide.
- **Identity source** — where Identity Center reads users and groups from. Three options: an external SAML 2.0 IdP with SCIM (Okta, Entra ID, Google Workspace, OneLogin, JumpCloud), AWS Managed Microsoft AD, or the Identity Center's own directory.
- **Permission sets** — reusable AWS access definitions. Each permission set bundles AWS-managed and customer-managed policies, an optional inline policy, a session duration (up to 12 hours), and optional permissions boundary.
- **Account assignments** — the mapping of (group or user) × permission set × AWS account.
- **Application assignments** — Identity Center can also federate into AWS-managed applications (Q Business, IAM-aware applications) and arbitrary SAML 2.0 applications.

Request flow for AWS Console access:

1. User opens the AWS access portal (https://your-org.awsapps.com/start).
2. Identity Center redirects to the IdP for authentication.
3. IdP authenticates the user (password + MFA) and returns a SAML assertion.
4. Identity Center validates the assertion and shows the user the AWS accounts and permission sets they have access to.
5. User clicks an account/permission-set tile.
6. Identity Center calls STS:AssumeRoleWithSAML to issue short-lived credentials and either redirects to the AWS Console or returns a CLI access string (`aws sso login` flow).
7. CloudTrail logs the AssumeRole event with the user's principal name, IdP, and session tags.

## Step 1: Configure the identity source

Pick the IdP that matches your workforce identity strategy. For most enterprises this is Okta or Entra ID.

**For Okta:**

```bash
# Identity Center accepts the SAML 2.0 metadata XML from Okta
aws sso-admin update-instance-access-control-attribute-configuration ...
# Then on the Okta side, add the AWS IAM Identity Center app from the Okta catalog and configure SCIM
```

The two-side dance — SAML for authentication, SCIM for provisioning — is well-documented for both Okta and Entra ID and takes a few hours end-to-end. Test with a non-production Identity Center instance first.

**For Entra ID:**

The configuration uses the "AWS IAM Identity Center" enterprise application from the Entra ID gallery. Enable user and group provisioning via SCIM; map the Entra ID groups you want to use for AWS access; assign users to those groups.

**Avoid the Identity Center directory for production.** It works but offers a worse identity lifecycle than a real IdP. Use it only for proof-of-concept environments.

## Step 2: Design permission sets

Permission sets are the AWS-side primitive for "what can this user do." Best practices:

- **One permission set per role, not per person.** Reuse permission sets across many account assignments.
- **Layer AWS-managed policies first, customer-managed policies second.** AWS-managed policies (like `ReadOnlyAccess`, `PowerUserAccess`, `AdministratorAccess`) are versioned and updated by AWS for new services; customer-managed policies fill the gaps.
- **Cap session duration aggressively.** 12 hours is the maximum; 4-8 hours is appropriate for production; 1 hour for sensitive break-glass roles.
- **Use permissions boundaries for elevated permission sets.** A permission set that includes `iam:*` should always carry a permissions boundary preventing self-escalation.
- **Inline policies sparingly.** They drift; prefer customer-managed policies.

A typical permission-set library:

| Permission set   | AWS-managed              | Customer-managed                       | Session |
| ---------------- | ------------------------ | -------------------------------------- | ------- |
| `ReadOnlyAccess` | ReadOnlyAccess           | n/a                                    | 8h      |
| `PowerUser`      | PowerUserAccess          | n/a                                    | 4h      |
| `Engineer`       | n/a                      | engineer-policy (workload-scoped)      | 4h      |
| `DataEngineer`   | n/a                      | data-engineer-policy (lake + Redshift) | 4h      |
| `BillingViewer`  | AWSBillingReadOnlyAccess | n/a                                    | 8h      |
| `Admin`          | AdministratorAccess      | + permissions boundary                 | 1h      |

Assign permission sets to (group, account) tuples. Avoid (user, account) — group-based assignments survive personnel changes cleanly.

## Step 3: Implement ABAC with session tags

Permission sets carry session tags propagated from IdP attributes through SCIM. Map the IdP attribute (e.g. `costCenter`, `team`, `environment_access`) to a session tag, and write Condition statements in policies that reference `aws:PrincipalTag/<tag>`.

Example policy granting access to resources tagged with the same Environment as the principal:

```json
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::data-lake/*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"
    }
  }
}
```

A user with `Environment=prod` session tag can access resources tagged `Environment=prod` only. A user with `Environment=dev` accesses dev resources only. New environments get their own tag — no policy change needed.

## Step 4: Enable identity propagation

Identity propagation is the high-value 2024-2026 feature. Configure Identity Center as a "trusted token issuer" for the downstream AWS-aware service:

- **Amazon Q Business** — Identity Center identity is the unit of access; document permissions evaluate against the user, RAG retrieval scopes to documents the user can read.
- **Amazon Redshift** — federated identity-aware queries; row-level security policies evaluate against the user; CloudTrail and Redshift audit logs show the user.
- **Amazon QuickSight** — Enterprise edition supports IAM Identity Center authentication; row-level security uses the user identity.
- **Amazon S3 Access Grants** — per-user S3 prefix permissions enforced at the data-plane via STS:AssumeRoleWithIdentityContext; no per-user IAM role per user.
- **AWS Glue** — interactive sessions and jobs run with the propagated user identity.
- **Amazon Q Developer** — propagated identity for line-of-business attribution.

The configuration pattern:

1. Confirm Identity Center is the identity source for the downstream service (in the service console: "Connect to IAM Identity Center").
2. Enable "Trusted Identity Propagation" on the connection.
3. Configure the application-side mapping (e.g. Redshift database user mapped to Identity Center user; QuickSight namespace mapped to Identity Center group).
4. Verify CloudTrail logs show the user-name, not just the assumed-role ARN.

The audit-log delta is large: a Redshift query that previously appeared as `arn:aws:sts::111122223333:assumed-role/QuickSightServiceRole/QuickSightSessionId` now appears with the user name, the Identity Center session ID, and the permission set used.

## Step 5: Migrate off long-lived IAM users

For an existing AWS Organization with established IAM users:

1. **Inventory.** List every IAM user. Tag with `human / programmatic / unknown`.
2. **Replace human IAM users.** Each human gets an IdP account → Identity Center group → permission set assignment. Once the human can do their work through Identity Center, delete the IAM user.
3. **Replace programmatic IAM users with OIDC federation.** GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Buildkite — all support OIDC federation into AWS. Configure an IAM role with a trust policy that accepts the OIDC token; the CI workflow assumes the role with no long-lived key.
4. **Replace programmatic IAM users for AWS-internal services with IAM roles.** Lambda, ECS task, EC2 instance roles — they should never be a long-lived IAM user.
5. **Replace third-party SaaS IAM users where possible.** Many third-party tools now support OIDC or IAM cross-account-role assumption. Where they do not, the IAM user is the rare legitimate case — keep it, rotate its access key on a tight schedule (90 days), and document why.
6. **IAM Access Analyzer.** Run the external access analyzer at the Organization level. It surfaces remaining IAM users with broad permissions — drive each to remediation.

Typical outcome at the end of a 6-12 month migration: zero human IAM users, single-digit programmatic IAM users (legacy SaaS), and 100% workforce access through Identity Center.

## Common pitfalls

1. **Treating Identity Center as just a console login portal.** The real value since 2023 is identity propagation; if you stop at the Console SSO experience, you miss the bigger story — per-user audit trails, row-level security, and S3 Access Grants all depend on it.
2. **Permission-set explosion.** Some teams end up with 50+ permission sets for trivial differences. Consolidate around RBAC roles and use ABAC for the per-team / per-environment differentiation.
3. **Not enforcing MFA at the IdP.** Identity Center honors the IdP's MFA — make sure the IdP requires MFA for AWS access. AWS-side, the new "MFA for root" requirement is unrelated and applies separately.
4. **Skipping SCIM.** Manual user sync is the source of most "the IT team forgot to deprovision" findings. SCIM-provisioned groups and users sync automatically on the IdP-side change.
5. **Not propagating session tags.** Identity Center session tags only flow downstream if you grant `sts:TagSession` in the assumed-role trust policy. Forgetting this breaks ABAC silently.

## Where to go next

- Read the **[AWS IAM Identity Center User Guide](https://docs.aws.amazon.com/singlesignon/)** and the **[trusted identity propagation guide](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-truste-identity-propagation.html)**.
- Pair with **[AWS Verified Access](/blog/aws-verified-access-ztna-zero-trust-network/)** for workforce app access using the same Identity Center identity.
- Pair with **[AWS IAM best practices](/blog/aws-iam-best-practices-least-privilege-access-control/)** for the cross-cutting IAM patterns.
- Browse the **[AWS Security & Compliance hub](/security-compliance/)** and the **[IAM & Access Control subtopic](/security-compliance/iam-access-control/)**.

Identity Center is the workforce-identity backbone for the next decade of AWS work. The migration is a multi-month effort but pays back continuously through reduced audit findings, cleaner deprovisioning, and the per-user audit trail that compliance frameworks now expect by default.

## FAQ

### When do we need IAM Identity Center vs Amazon Cognito?
Different problems. IAM Identity Center is the AWS-native workforce identity service: it federates your employees (from Okta, Microsoft Entra ID, Google Workspace, or its own directory) into AWS accounts, applications, and identity-aware services like Q Business, Redshift, QuickSight, and S3 Access Grants — propagating the human identity end-to-end so audit logs show who, not which IAM role. Cognito is a customer-facing user pool for your SaaS application end users — sign-up, sign-in, MFA, social/SAML federation, and JWT issuance. Most platforms run both: Identity Center for staff and admins, Cognito for tenants. They are not interchangeable, and AWS has not merged User Pools and Identity Pools as some 2023 commentary suggested.

### What is identity propagation and why does it matter?
Identity propagation passes the authenticated workforce identity through to AWS-native services so the user identity (not a service IAM role) appears in audit logs and access decisions. With identity propagation, when a user runs a query in Amazon Redshift, the row-level security policies evaluate against the user identity, the audit log shows the user not the BI tool service role, and S3 Access Grants enforce per-user permissions on the data lake. Services that support identity propagation today: Amazon Q Business, Amazon Q Developer, Amazon Redshift (federated identity-aware queries), Amazon QuickSight, Amazon S3 Access Grants, and AWS Glue. Without identity propagation, the audit log shows generic role activity and you lose per-user accountability — a frequent finding in HIPAA / SOC 2 / DORA audits.

### How does Identity Center federation from Okta or Entra ID actually work?
Configure Okta or Entra ID as a SAML 2.0 IdP in Identity Center, then enable SCIM provisioning so user and group changes in the IdP push automatically to Identity Center (no manual user sync). Users authenticate at the IdP login page; the IdP issues a SAML assertion; Identity Center accepts the assertion and issues short-lived AWS credentials (via the AWS access portal for console users or `aws configure sso` for CLI users). Permission sets — managed-policy collections plus inline policies and a session duration up to 12 hours — are assigned to AWS accounts via Identity Center groups (which mirror IdP groups via SCIM). New IdP users provisioned into the right group inherit the right AWS permissions automatically; user departure in the IdP removes AWS access on the next SCIM sync.

### Can ABAC actually work in production with Identity Center?
Yes, and Identity Center is the preferred way to do ABAC at AWS Organization scale. The pattern: enforce mandatory tags on every resource via Service Control Policies (e.g. `aws:ResourceTag/CostCenter` and `aws:ResourceTag/Environment` required on creation), pass principal tags via Identity Center session tagging (mapped from IdP attributes through SCIM), then write a small number of permission sets that read those tags via Condition statements. New teams or environments do not need new permission sets — they need a tag. The first 90 days are tag-cleanup hell; after that, ABAC scales further than RBAC and audits cleaner because the policy text does not enumerate every team. Identity Center session tags are propagated through STS-assumed roles via IAM`sts:TagSession` permission so downstream policies (S3 Access Grants, Redshift row-level security) can read them.

### What about long-lived IAM users — should we delete them all?
Yes, with rare exceptions. The 2024-2026 AWS security baseline is: zero long-lived IAM users for human access. Workforce humans go through Identity Center → SAML/OIDC IdP. Programmatic access uses IAM roles assumed by services or by short-lived federated credentials. The rare legitimate IAM user is third-party SaaS that requires a long-lived access key (some legacy CI/CD tools, legacy backup vendors) — and even there, the modern pattern is OIDC federation (GitHub Actions, GitLab CI, BitBucket Pipelines all support OIDC into AWS). The IAM Access Analyzer external-access findings will surface long-lived IAM users with broad permissions; treat each as a remediation ticket. Auditors increasingly flag every long-lived IAM user as a finding under "least privilege" or "credential rotation" controls.

---

*Source: https://www.factualminds.com/blog/aws-iam-identity-center-workforce-sso-identity-propagation/*