mrvitej.in
Happy Dussehra! May good always win. Happy Diwali! Wishing you a bright year ahead. Merry Christmas! Warm wishes from Vizag. Happy New Year! Here’s to a great year ahead.

Archive · AWS

AWS SSO Is Now IAM Identity Center

Set up single sign-on across AWS accounts with groups, permission sets and short-lived credentials, and use it from the CLI instead of IAM users and long-lived keys.

4 min read

  • IAM Identity Center
  • AWS Organizations
  • AWS CLI 2.7
  • Permission sets

On 26 July 2022 AWS Single Sign-On was renamed AWS IAM Identity Center. The service is the same, and it is the recommended way for people to reach many AWS accounts. Instead of an IAM user with access keys in each account, people sign in once and receive temporary credentials for the role they were assigned.

Versions in use on this date. AWS CLI 2.7 (v2 is required for aws configure sso) and AWS Organizations. The Identity Center is enabled in one region of the management account and its instance is organization-wide.

Model

flowchart TB
  IDP[Identity source - built-in directory or Active Directory or external IdP via SAML] --> U[Users and groups]
  U --> ASSIGN{Assignments: group + permission set + account}
  PS1[Permission set ReadOnly] --> ASSIGN
  PS2[Permission set Developer] --> ASSIGN
  PS3[Permission set Admin] --> ASSIGN
  ASSIGN --> ROLE1[IAM role created in dev account<br/>AWSReservedSSO_Developer_...]
  ASSIGN --> ROLE2[IAM role created in prod account<br/>AWSReservedSSO_ReadOnly_...]
  USER[Person signs in at access portal<br/>with MFA] --> ASSIGN
  USER -->|temporary credentials, hours| CLI[Console, CLI, SDKs]

Key terms: identity source (where users live), group (assign access to groups, never to individuals), permission set (a template of IAM policies and a session duration), and assignment (group + permission set + account). Identity Center creates and manages an IAM role in each target account for every assignment.

Setting it up

  1. In the management account, enable AWS Organizations, then enable IAM Identity Center in your chosen home region.
  2. Choose the identity source. Start with the built-in directory for a small team, or connect your company IdP (Azure AD, Okta, Google Workspace) with SAML and SCIM provisioning so joiners and leavers flow automatically.
  3. Create groups that match jobs: platform-admins, developers, auditors.
  4. Create permission sets, for example:
    • ReadOnly: the AWS managed ViewOnlyAccess or ReadOnlyAccess policy, 8-hour session.
    • Developer: a customer policy allowing the services the team uses, no IAM write, 4-hour session.
    • Admin: AdministratorAccess, short session (1 hour), assigned to a very small group.
  5. Assign groups to accounts: developers get Developer in dev and ReadOnly in prod.
  6. Require MFA for all users (Settings, Authentication) and give people the portal URL https://<alias>.awsapps.com/start.

Using it from the CLI

aws configure sso
# SSO session or start URL: https://acme.awsapps.com/start
# SSO region: ap-south-1
# choose account and role, name the profile, e.g. prod-readonly

aws sso login --profile prod-readonly            # opens the browser for sign-in and MFA
aws sts get-caller-identity --profile prod-readonly
aws s3 ls --profile prod-readonly
export AWS_PROFILE=prod-readonly
aws sso logout

Profile created in ~/.aws/config:

[profile prod-readonly]
sso_start_url = https://acme.awsapps.com/start
sso_region = ap-south-1
sso_account_id = 111122223333
sso_role_name = ReadOnly
region = ap-south-1

SDKs and tools that support the SSO credential provider (current AWS SDKs, Terraform’s AWS provider with a profile) can use the same profile. For tools that still expect static keys, run aws sso login first and let them read the profile through the CLI credential chain.

Why it beats long-lived IAM users

Concern IAM users and keys Identity Center
Credentials Keys can sit in files for years and leak Temporary, expire in hours
Offboarding Remove user in every account Disable once at the directory
MFA Per user, per account Central, enforced
Many accounts Separate users per account or role-chaining One sign-in, many roles
Auditing Separate identities CloudTrail shows the SSO user name on role sessions

Guardrails

  • Use the management account only for Organizations and Identity Center administration. Run workloads elsewhere, and restrict who can administer Identity Center.
  • Combine with service control policies to block dangerous actions (disabling CloudTrail, leaving the organization) even for admins.
  • Break glass: keep a documented emergency IAM role or root access procedure, protected by hardware MFA and monitored with alarms on its use. Test it twice a year so it works when you need it.
  • Machines are different: do not use SSO users for automation. Use IAM roles for workloads and OIDC for CI (for example GitHub Actions).
  • Review assignments quarterly; remove stale groups, and keep permission sets few and well named.

Troubleshooting

  • “The SSO session associated with this profile has expired”: run aws sso login again.
  • Not seeing an account in the portal: the group lacks an assignment for that account, or the user is not in the group.
  • Access denied after a permission set change: re-provision the permission set to its accounts and wait a minute, then sign in again.
  • CLI opens no browser: use aws sso login --no-browser and open the printed URL on any device.