Alright, let’s talk about IAM Identity Center, formerly known as SSO. I know, I know, another AWS rebranding. They changed the name because it does a heck of a lot more than just single sign-on, and frankly, “AWS SSO” was a nightmare to search for. This service is your golden ticket for managing human access across your entire AWS organization. Trying to manage users in every single account individually is like trying to herd cats on a skateboard—pointless and painful.

IAM Identity Center is your central directory. You define your users (or connect it to your real directory like Active Directory), and then you control what they can access in any of your AWS accounts. No more creating IAM users everywhere. This is a massive win for security and your sanity.

The Core Concepts: User, Permission Set, and Assignment

Think of it like this: a User (or Group) is who needs access. A Permission Set is what they can do (it’s essentially a collection of policies). The Assignment is the magic that connects the who to the what in a specific where (account).

Permission Sets are just fancy IAM policies on steroids. You can attach managed policies, inline policies, and even set session durations. The real power, and where most people’s brains short-circuit, is in the assignments. You don’t just assign a user to an account; you assign a permission set for a user (or group) to a specific account.

# Let's say you have a Developer, Alice, who needs read-only EC2 access in the Dev account
# and full S3 access in the Staging account. You'd create two separate assignments.

# First, create the Permission Sets in your Identity Center instance (management account)
# This is often done via the console, but here's the AWS CLI v2 equivalent.

# Create a Permission Set for ReadOnly EC2 access
aws sso-admin create-permission-set \
  --instance-arn "arn:aws:sso:::instance/ssoins-1234567890abcdef" \
  --name "ReadOnlyEC2" \
  --description "Read-only access to EC2 services" \
  --session-duration PT1H \
  --relay-state "https://us-east-1.console.aws.amazon.com/ec2/home"

# Now attach a managed policy to it
aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn "arn:aws:sso:::instance/ssoins-1234567890abcdef" \
  --permission-set-arn "arn:aws:sso:::permissionSet/ssoins-1234567890abcdef/ps-abcdef1234567890" \
  --managed-policy-arn "arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess"

# Then, you assign Alice to the Dev account with this Permission Set
aws sso-admin create-account-assignment \
  --instance-arn "arn:aws:sso:::instance/ssoins-1234567890abcdef" \
  --permission-set-arn "arn:aws:sso:::permissionSet/ssoins-1234567890abcdef/ps-abcdef1234567890" \
  --principal-type USER \
  --principal-id "a1b2c3d4-5678-9012-3456-7890abcdef12" \ # Alice's ID in Identity Center
  --target-id "123456789012" \ # The Dev Account ID
  --target-type AWS_ACCOUNT

You’d then repeat the process for the S3Admin permission set in the Staging account. This granularity is what makes it powerful.

The Portal: Where the Magic (and Confusion) Happens

When your users log in, they don’t go to the AWS console. They go to your custom Identity Center portal URL. This is the “choose your own adventure” screen where they pick which account and which role they want to assume. This is the part that confuses everyone at first because it’s a completely different mental model. They’re not logging into an account; they’re asking to assume a role in an account, and the portal is the menu.

The Rough Edges and Pitfalls

Here’s the stuff the marketing page won’t tell you.

  1. The CLI is… particular. The AWS CLI v2 has commands for sso-admin (for configuring Identity Center) and identitystore (for managing users/groups). They are powerful but verbose and require you to juggle ARNs like a circus act. You will live and die by the --instance-arn and --permission-set-arn flags. Using AWS CloudShell or writing a script is highly recommended over typing these by hand.
  2. Service Roles are a Separate Problem. Identity Center is for people. It doesn’t solve the problem of an EC2 instance in Dev needing to access an S3 bucket in Staging. For that, you still need traditional IAM Roles and trust policies. Don’t mix up your human access and machine access patterns.
  3. Permission Set Limits. There’s a default limit of 1000 permission sets per instance. You’ll likely hit the “why are my API calls so slow?” wall long before you hit that limit. Keeping your permission sets generalized and re-used across assignments is a critical best practice. If you’re creating a unique permission set for every single user, you’re doing it wrong and your configuration will become unmanageable sludge.
  4. The “Session Duration” Gotcha. You set the maximum session duration in the Permission Set. But guess what? Your user can choose a shorter duration from the portal dropdown when they sign in. This is great for security, but it can lead to confusing “my session expired already” tickets if your devs keep selecting the 15-minute option.

The best practice is to use Groups religiously. Assign permission sets to groups, not individual users. It scales. When a new developer joins, you add them to the “Developers” group, and they instantly get the correct access to all the right accounts. It’s the difference between plugging in one cable and rewiring the entire building.