AWS Security & Identity
IAM Identity Center
Centralized SSO and permissions management across multiple AWS accounts
AWS IAM Identity Center (formerly AWS SSO) provides centralized single sign-on and permission management across all AWS accounts in an AWS Organization. It replaces the need to create IAM users in every account and integrates with external identity providers like Okta, Azure AD, and Google Workspace. It is the recommended approach for human access in any multi-account AWS environment.
How IAM Identity Center Works
IAM Identity Center sits at the management account level and federates identities from a connected identity source into permission sets that are assigned to accounts. When a user signs in, they receive temporary credentials scoped to the account and permission set they select.
| Component | Description |
|---|---|
| Identity Source | Where users and groups live - can be Identity Center built-in directory, Active Directory, or external IdP (Okta, Azure AD, Google) |
| Permission Set | A named collection of IAM policies that defines what a user can do in an account. Maps 1:1 to an IAM role in each assigned account. |
| Account Assignment | Links a user or group to a permission set in a specific AWS account |
| AWS Access Portal | The web UI users log into to see their assigned accounts and roles |
| SCIM provisioning | Automatic sync of users and groups from an external IdP into Identity Center |
When a user assumes a permission set, Identity Center creates a role in the target account (named like AWSReservedSSO_PermissionSetName_randomhex) and issues time-limited credentials via STS.
Identity Sources: Built-in vs External IdP vs Active Directory
| Identity Source | Best for | Sync method | MFA handling |
|---|---|---|---|
| Identity Center built-in | Small teams, no existing IdP | Manual user creation | Identity Center manages MFA |
| AWS Managed Microsoft AD | Enterprises already using AD | AD Connector or AWS Managed AD | AD Group Policy / MFA server |
| External IdP (SAML 2.0) | Okta, Azure AD, Google Workspace, Ping | SCIM push from IdP | IdP handles MFA (Okta MFA, Azure MFA) |
For most enterprises, connecting an external IdP via SAML + SCIM is the right choice. SCIM ensures that when an employee leaves and is deprovisioned in Okta, they lose AWS access within minutes automatically.
The identity source can only be changed by deleting all current assignments. Plan your identity source decision carefully before onboarding users at scale.
Designing Permission Sets for Multi-Account Access
Permission sets are the unit of authorization in IAM Identity Center. They can attach AWS-managed policies, customer-managed policies, and inline policies. A well-designed permission set library covers developer, read-only, ops, and admin personas.
| Permission Set | Policies attached | Assigned to |
|---|---|---|
| ReadOnly | ReadOnlyAccess managed policy | All developers in all accounts |
| Developer | PowerUserAccess - iam:* + billing:* | Dev account developers |
| DBAAccess | Custom policy scoped to RDS and Secrets Manager | DBAs in prod account |
| PlatformAdmin | AdministratorAccess | Platform team in all accounts |
| BillingViewer | AWSBillingReadOnlyAccess | Finance team in management account |
# Assign a permission set to a group in an account via CLI
aws sso-admin create-account-assignment \
--instance-arn arn:aws:sso:::instance/ssoins-xxx \
--target-id 123456789012 \
--target-type AWS_ACCOUNT \
--permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxx/ps-yyy \
--principal-type GROUP \
--principal-id <group-id>CLI and Programmatic Access via Identity Center
Developers can use IAM Identity Center for CLI access via the AWS CLI v2 SSO integration, eliminating the need for long-term access keys.
# Configure a named profile backed by IAM Identity Center
aws configure sso
# Follow prompts: start URL, region, account, permission set
# Result in ~/.aws/config:
# [profile dev-poweruser]
# sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
# sso_region = us-east-1
# sso_account_id = 123456789012
# sso_role_name = PowerUserAccess
# Log in and get temporary credentials
aws sso login --profile dev-poweruser
# Use the profile
aws s3 ls --profile dev-poweruser
# List all available accounts and roles
aws sso list-accounts --access-token <token>
aws sso list-account-roles --account-id 123456789012 --access-token <token>AWS CLI v2 caches SSO tokens automatically. Tokens expire after 8 hours by default (configurable). For CI/CD pipelines, use OIDC federation with IAM roles instead - Identity Center is designed for human access.
IAM Identity Center vs IAM Users for Human Access
| Aspect | IAM Users (old pattern) | IAM Identity Center (modern pattern) |
|---|---|---|
| User management | Manual creation in each account | Centralized, synced from IdP |
| Access keys | Long-term keys stored in ~/.aws/credentials | Temporary credentials, expire automatically |
| Multi-account | Separate user per account or complex cross-account roles | Single login, choose account at sign-in |
| Offboarding | Must remember to delete user in every account | Remove from IdP, SCIM deprovisioning handles the rest |
| MFA enforcement | Per-user setting, easy to miss | Enforced at IdP level, no exceptions |
| Audit trail | CloudTrail shows IAM user ARN | CloudTrail shows identity center session with user email |
Creating IAM users for human access in a multi-account organization is a security antipattern. The only IAM user that should exist in a well-governed account is an emergency break-glass user, stored with keys in a vault and protected by MFA.
Interview Focus Points
- 1What is the difference between IAM Identity Center and traditional IAM users? Why would you prefer Identity Center in a multi-account setup?
- 2How does SCIM provisioning work and why does it matter for offboarding security?
- 3What is a permission set and how does it map to IAM roles in target accounts?
- 4How would you set up developer CLI access without issuing long-term access keys?
- 5A developer leaves the company. Walk me through exactly how their AWS access is revoked in an IAM Identity Center setup with Okta as the IdP.
- 6What are the limitations of IAM Identity Center vs direct role assumption for CI/CD pipelines?
- 7How does MFA enforcement work when using an external IdP like Azure AD with Identity Center?
- 8Can you use IAM Identity Center for non-human service account access? What is the recommended alternative?