IAM Identity Center

IAM Identity Center (formerly AWS SSO) is the recommended way to manage human access to AWS accounts and business applications. It provides a single sign-on experience across all your AWS accounts in an organization.

Key Features

• Centralized Access: one place to manage access to all AWS accounts
• Permission Sets: reusable sets of IAM policies assigned to users/groups for specific accounts
• Identity Sources: built-in directory, Active Directory (AD Connector or AWS Managed AD), or external IdP (Okta, Azure AD, Ping)
• MFA: built-in MFA with WebAuthn/FIDO2, authenticator apps, and RADIUS
• Application Assignments: SSO access to SAML 2.0 applications (Salesforce, Slack, etc.)

Why Use It

• Eliminates IAM users - no more long-term credentials for humans
• Centralized audit trail of who accessed which account
• Automatic credential rotation (temporary credentials via STS)
• Works with AWS Organizations for multi-account management

How Permission Sets Actually Work

A permission set is not itself an IAM entity; it is a template. When you assign a permission set to a user or group for a given account, Identity Center provisions a corresponding IAM role into that account and keeps it in sync. When the user signs in through the access portal and picks an account and permission set, they get temporary credentials for that provisioned role. This mental model explains most day-two questions: why changing a permission set takes effect only after re-provisioning to accounts, why the roles it creates should never be edited by hand in member accounts, and why CloudTrail in each account shows role sessions whose names carry the user's identity, giving you per-human attribution without any IAM users.

Design permission sets like you design IAM policies: a small catalog of well-named, least-privilege sets (read-only, developer, ops, billing) assigned to groups rather than individuals. Group membership then becomes the single control point for access, which is exactly what auditors want to see.

How It Goes Wrong in Practice

The most damaging pattern is the administrator permission set as default. Rolling out Identity Center under time pressure, a team creates one permission set based on AdministratorAccess, assigns it to the "Engineering" group across all accounts, and promises to tighten later. Every engineer is now a full admin everywhere, and a single phished workforce credential carries organization-wide blast radius. The whole point of the permission set model, cheap fine-grained assignments, goes unused. Pair least-privilege sets with strong MFA (WebAuthn/FIDO2 resists phishing far better than one-time codes) because Identity Center concentrates access: it is the front door to everything.

A second recurring issue is orphaned assignments and stale groups. When the identity source is an external IdP, offboarding must flow from the IdP through provisioning into Identity Center. If provisioning breaks silently or contractors are managed in a side group nobody reviews, departed users can retain a working sign-in path to production accounts. Review assignments and identity-source sync health as part of your access recertification cycle.

Practical Check: Confirm Your Instance and Inventory Access

Start by identifying your Identity Center instance, which anchors every other CLI call:

aws sso-admin list-instances

The output includes the InstanceArn, IdentityStoreId, OwnerAccountId, status, and Region information for each instance visible to the calling account. From there, the sso-admin command set lets you enumerate permission sets and account assignments, and the identitystore command set lets you list users and groups; together they give you a scriptable answer to "who can access what", the question that matters in every audit.

Frequently Asked Questions

Is IAM Identity Center the same thing as IAM?

No. IAM is the underlying permission system in every account. Identity Center is a management layer above it for workforce access: it stores (or federates) your human identities and provisions IAM roles into accounts based on permission set assignments. The credentials people end up using are ordinary STS temporary credentials.

Do I still need IAM users if I adopt Identity Center?

For humans, no, and removing them is the main win. Workloads should use IAM roles. What remains are rare break-glass or legacy-tool cases, which should be tightly monitored exceptions.

Can developers use the CLI with Identity Center?

Yes. AWS CLI v2 supports SSO sign-in natively: configure a profile with your access portal URL, authenticate in the browser, and the CLI obtains short-lived credentials for the selected account and permission set, no access keys involved.