AWS SSO (IAM Identity Center)

Oct 22, 2024

Overview

AWS IAM Identity Center (formerly AWS SSO) provides centralized single sign-on access to multiple AWS accounts and business applications. It is built on top of AWS Organizations — you must enable Organizations before setting up Identity Center.

Cost: Both AWS Organizations and IAM Identity Center are free. You only pay for the resources in your accounts.
Region: Identity Center is deployed in a single home region — choose carefully as it cannot be changed later.
Identity sources: Identity Center directory (built-in — no external IdP needed), Microsoft Active Directory, or external IdP (SAML 2.0 — e.g., Okta, Azure AD, Google Workspace).
Instance ID: Starts with ssoins- (e.g., ssoins-7223e96813b69a54). Found in Identity Center settings.
Identity Store ID: Starts with d-. Needed for user/group CLI commands.

Method	Sign-in URL	Use Case
Root user	`console.aws.amazon.com` → root email + password	Emergency only, account owner
IAM user	`https://<account-id>.signin.aws.amazon.com/console`	Legacy per-account access (deprecated for humans)
SSO (Identity Center)	`https://yourname.awsapps.com/start`	Recommended for all human access

These are completely independent authentication systems. An IAM user and an Identity Center user with the same email are not linked.

IAM Users vs Identity Center Users

Aspect	IAM User	Identity Center User
Scope	Single AWS account	All accounts in the organization
Credentials	Password + long-lived access keys	Password + MFA, temporary credentials
Best for	Break-glass admin, service accounts	Day-to-day human access
AWS recommendation	Avoid for humans	Preferred for all human users

After SSO is set up, you should not need IAM users for human access. Use IAM roles for service/application access (e.g., EC2 instance roles, Lambda execution roles).

Recommended Daily Setup

Purpose	Use
Daily access (Console/CLI)	Identity Center (SSO)
Emergency / break-glass	Root user (management account) with MFA
Service/application access	IAM roles (not IAM users)

Step 1: Create AWS Organizations

AWS Organizations lets you centrally manage multiple AWS accounts. The account that creates the organization becomes the management account.

Via AWS Console

Sign in to the AWS Organizations Console with the account you want as the management account.
Click Create an organization.
Select All features (required for IAM Identity Center).
Your current account is now the management account.

Via AWS CLI

# Create the organization with all features enabled
aws organizations create-organization --feature-set ALL

Best practice: Do not run production workloads in the management account. Use it only for billing, Organizations, and Identity Center management.

Step 2: Create Organizational Units (OUs)

OUs help you group accounts by purpose (e.g., production, development, security). This makes it easier to apply policies and manage access.

Via AWS Console

In the AWS Organizations console, go to AWS accounts.
Select the Root node.
Click Actions → Create new.
Enter a name (e.g., Production, Development, Security).

Via AWS CLI

# Get the root ID first
aws organizations list-roots

# Create OUs under root
aws organizations create-organizational-unit \
  --parent-id r-xxxx \
  --name "Production"

aws organizations create-organizational-unit \
  --parent-id r-xxxx \
  --name "Development"

aws organizations create-organizational-unit \
  --parent-id r-xxxx \
  --name "Security"

Step 3: Create or Invite Member Accounts

You can either create new accounts directly from Organizations or invite existing accounts to join.

Option A: Create a New Account

In Organizations console → AWS accounts → Add an AWS account.
Choose Create an AWS account.
Enter account name, email (must be unique globally), and IAM role name (default: OrganizationAccountAccessRole).
Click Create.

# Via CLI
aws organizations create-account \
  --email "dev-account@example.com" \
  --account-name "Development Account"

# Check creation status
aws organizations describe-create-account-status \
  --create-account-request-id car-xxxxxxxxxx

Option B: Invite an Existing Account

In Organizations console → Add an AWS account → Invite an existing AWS account.
Enter the account ID or email of the account to invite.
The target account owner must accept the invitation in their AWS Organizations console.

# Via CLI
aws organizations invite-account-to-organization \
  --target '{"Type": "ACCOUNT", "Id": "123456789012"}'

# Target account accepts the invitation
aws organizations accept-handshake \
  --handshake-id h-xxxxxxxxxx

Move Accounts to OUs

# Move an account from Root to an OU
aws organizations move-account \
  --account-id 123456789012 \
  --source-parent-id r-xxxx \
  --destination-parent-id ou-xxxx-xxxxxxxx

Step 4: Enable IAM Identity Center (SSO)

Via AWS Console

In the management account, go to IAM Identity Center.
Click Enable.
Choose your preferred region (this will be the home region for Identity Center).
Identity Center is now active.

Via AWS CLI

# Enable IAM Identity Center instance
aws sso-admin create-instance

Step 5: Choose an Identity Source

The identity source determines where your users and groups are managed.

Source	Best For	Notes
Identity Center directory	Small teams, quick setup	Built-in, manage users directly in AWS
Active Directory	Enterprises with existing AD	Use AWS Managed Microsoft AD or AD Connector
External IdP (SAML 2.0)	Okta, Azure AD, Google Workspace	Federated sign-in, SCIM provisioning supported

To Change Identity Source (Console)

IAM Identity Center → Settings → Identity source tab.
Click Actions → Change identity source.
Select your source and follow the configuration wizard.

Step 6: Create Users and Groups

If using the built-in Identity Center directory:

Create a Group

IAM Identity Center → Groups → Create group.
Enter group name (e.g., Developers, Admins, ReadOnly).
Add users to the group (can also be done later).

Create a User

IAM Identity Center → Users → Add user.
Enter: username, email, first name, last name.
Optionally add the user to groups.
The user receives an email to set up their password.

Via AWS CLI

# Get the Identity Store ID (from Identity Center settings)
IDENTITY_STORE_ID="d-xxxxxxxxxx"

# Create a group
aws identitystore create-group \
  --identity-store-id $IDENTITY_STORE_ID \
  --display-name "Developers" \
  --description "Developer team"

# Create a user
aws identitystore create-user \
  --identity-store-id $IDENTITY_STORE_ID \
  --user-name "jdoe" \
  --name '{"GivenName": "John", "FamilyName": "Doe"}' \
  --emails '[{"Value": "jdoe@example.com", "Primary": true}]' \
  --display-name "John Doe"

# Add user to group
aws identitystore create-group-membership \
  --identity-store-id $IDENTITY_STORE_ID \
  --group-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --member-id '{"UserId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}'

Step 7: Create Permission Sets

Permission sets define what level of access users/groups get when assigned to an AWS account. They map to IAM roles created automatically in each assigned account.

Via AWS Console

IAM Identity Center → Permission sets → Create permission set.
Choose a type:
- Predefined: AWS managed policies like AdministratorAccess, ViewOnlyAccess, PowerUserAccess.
- Custom: Attach specific AWS managed policies, customer managed policies, or inline policies.
Set session duration — this is the role session duration (how long credentials last in a specific account). See guidance below.
Optionally set a relay state (URL to redirect users to after sign-in — usually leave blank).

Via AWS CLI

# Get the SSO instance ARN
SSO_INSTANCE_ARN=$(aws sso-admin list-instances \
  --query "Instances[0].InstanceArn" --output text)

# Create a permission set
aws sso-admin create-permission-set \
  --instance-arn $SSO_INSTANCE_ARN \
  --name "DeveloperAccess" \
  --description "Developer level access" \
  --session-duration "PT4H"

# Attach an AWS managed policy to the permission set
aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn $SSO_INSTANCE_ARN \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxx/ps-xxxxxxxx \
  --managed-policy-arn arn:aws:iam::aws:policy/PowerUserAccess

# Attach an inline policy for fine-grained control
aws sso-admin put-inline-policy-to-permission-set \
  --instance-arn $SSO_INSTANCE_ARN \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxx/ps-xxxxxxxx \
  --inline-policy '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": ["organizations:*", "account:*"],
      "Resource": "*"
    }]
  }'

Common permission sets to create:

AdministratorAccess — full access (for account admins).
PowerUserAccess — full access except IAM/Organizations.
ViewOnlyAccess — read-only access for auditing.
BillingAccess — custom set with billing permissions only.

Session Duration Guidance

There are two separate session durations:

Session Type	What It Controls	Default	Max	Set Where
SSO portal session	How long you stay signed into the portal	8 hours	90 days	Settings → Authentication
Role session (permission set)	How long your credentials last in a specific account	1 hour	12 hours	Permission set settings

When the role session expires, you return to the portal and click the account again — no re-authentication needed if the portal session is still active.

Recommended role session durations:

AdministratorAccess → 1–4 hours (sensitive, keep short)
DeveloperAccess → 8 hours (covers a workday)
ViewOnlyAccess → 8–12 hours (low risk)

Step 8: Assign Users/Groups to AWS Accounts

This is where you connect who (users/groups) gets what access (permission set) to which account. The assignment is always a three-way link:

Group (or User)  +  AWS Account  +  Permission Set  =  Assignment

Always prefer assigning groups over individual users — even if you only have one user now. When you add more users later, just add them to the group and they automatically get the same access.

You can assign multiple permission sets to the same group on the same account (e.g., both AdministratorAccess and a custom set).

Via AWS Console

IAM Identity Center → AWS accounts.
Select one or more accounts → Assign users or groups.
Choose a group (preferred) or user.
Select one or more permission sets.
Click Submit.

Via AWS CLI

# Assign a group to an account with a permission set
aws sso-admin create-account-assignment \
  --instance-arn $SSO_INSTANCE_ARN \
  --target-id 123456789012 \
  --target-type AWS_ACCOUNT \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxx/ps-xxxxxxxx \
  --principal-type GROUP \
  --principal-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Repeat this for each account you want to onboard. A typical mapping:

Group	Account	Permission Set
Admins	All accounts	AdministratorAccess
Developers	Development	PowerUserAccess
Developers	Production	ViewOnlyAccess
Finance	Management	BillingAccess

Step 9: Configure the AWS Access Portal

After setup, users access AWS accounts through the AWS access portal.

IAM Identity Center → Settings → find the AWS access portal URL.
Customize the URL: click Customize to set a friendly subdomain (e.g., https://mycompany.awsapps.com/start).
Share this URL with your users.

When users sign in, they see all accounts and roles assigned to them and can click to open the AWS Console or copy CLI credentials.

Step 10: Enable MFA

Strongly recommended for all users.

IAM Identity Center → Settings → Authentication tab.
Click Configure under MFA.
Choose settings:
- Every time they sign in (most secure) or Only when sign-in context changes.
- Allow authenticator apps, security keys, and/or built-in authenticators.
- Choose whether to require MFA registration at next sign-in.

Step 11: Set Up CLI/SDK Access (Optional)

Users can get temporary credentials for CLI/SDK access through the portal or by configuring AWS CLI with SSO.

Configure AWS CLI with SSO

# Configure a named profile for SSO
aws configure sso
# You will be prompted for:
#   SSO session name: my-sso
#   SSO start URL: https://mycompany.awsapps.com/start
#   SSO region: us-east-1
#   SSO registration scopes: sso:account:access
# A browser opens to authenticate, then you select account and role.

# Use the profile
aws s3 ls --profile my-sso-profile

# Login again when session expires
aws sso login --profile my-sso-profile

Example ~/.aws/config

[sso-session my-sso]
sso_start_url = https://mycompany.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

[profile dev-account]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = DeveloperAccess
region = us-east-1

[profile prod-account]
sso_session = my-sso
sso_account_id = 987654321098
sso_role_name = ViewOnlyAccess
region = us-east-1

Onboarding Checklist for New Accounts

When adding a new AWS account to your organization and SSO:

Create or invite the account into AWS Organizations.
Move the account to the appropriate OU.
Apply SCPs (Service Control Policies) at the OU level if needed.
Assign groups to the account with appropriate permission sets in IAM Identity Center.
Notify users — they will see the new account in the AWS access portal automatically.
Set up account-level defaults (CloudTrail, Config, GuardDuty, etc.) — consider using AWS Control Tower to automate this.

Useful CLI Commands Reference

# List all accounts in the organization
aws organizations list-accounts

# List all OUs under root
aws organizations list-organizational-units-for-parent --parent-id r-xxxx

# List permission sets
aws sso-admin list-permission-sets --instance-arn $SSO_INSTANCE_ARN

# List account assignments for a permission set
aws sso-admin list-account-assignments \
  --instance-arn $SSO_INSTANCE_ARN \
  --account-id 123456789012 \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxx/ps-xxxxxxxx

# Provision (sync) a permission set to accounts after changes
aws sso-admin provision-permission-set \
  --instance-arn $SSO_INSTANCE_ARN \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxx/ps-xxxxxxxx \
  --target-type ALL_PROVISIONED_ACCOUNTS

# List users
aws identitystore list-users --identity-store-id $IDENTITY_STORE_ID

# List groups
aws identitystore list-groups --identity-store-id $IDENTITY_STORE_ID

Centralized Root Access

When centralized root access is enabled in AWS Organizations:

Member accounts no longer have root credentials — you cannot sign in to them as root.
Management account root still works normally.
Root-level privileged actions on member accounts are performed from the management account via IAM → Root access management.

Can’t Assume Root / Access Denied

If you see: “RootSession may not be assumed by root accounts” — this means you are signed in as the root user. The AssumeRoot feature is for IAM users/roles only, not root itself.

Fix: Sign in as an IAM user or SSO user with AdministratorAccess instead. Then you can:

Use IAM → Root access management → Take privileged action on member accounts (Console).
Use aws sts assume-root (CLI only — not available in Console).

Available Privileged Root Actions

# CLI only — assume root for specific tasks on member accounts
aws sts assume-root \
  --target-principal 123456789012 \
  --task-policy-arn '{"arn": "arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy"}'

# Available task policies:
# - arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy
# - arn:aws:iam::aws:policy/root-task/SQSUnlockQueuePolicy
# - arn:aws:iam::aws:policy/root-task/IAMAuditRootUserCredentials

Accessing Member Accounts Without Root

For general admin access to a member account, use Switch Role in the Console:

Sign in to the management account (as IAM user or SSO).
Click account name (top right) → Switch role.
Enter the member account ID and role name: OrganizationAccountAccessRole.
Click Switch Role.

Enabling Billing Access for Non-Root Users

Important: Even with AdministratorAccess or a policy with Action: * on Resource: *, IAM/SSO users cannot access Cost Explorer, Billing, or Cost Management by default. Billing is gated by a separate account-level setting that only root can change.

How to Enable (One-Time, As Root)

Sign in as root on the management account.
Click account name (top right) → Account.
Scroll to IAM user and role access to Billing information.
Click Edit → check Activate IAM Access → Update.

With centralized root access enabled, you cannot change this setting on member accounts individually. However, consolidated billing is at the management account level — Cost Explorer in the management account shows costs for all accounts in the organization. You only need to enable this setting on the management account.

Use the Account filter in Cost Explorer to break down spending per member account.

Troubleshooting

User can’t see an account in the portal: Check that the user/group is assigned to the account with a permission set.
Permission set changes not reflecting: Re-provision the permission set (IAM Identity Center → Permission sets → select set → Provision → All accounts).
CLI “Token has expired”: Run aws sso login --profile your-profile to refresh.
Cannot enable Identity Center: Ensure Organizations is enabled with All features (not just consolidated billing).
External IdP sync issues: Check SCIM endpoint configuration and bearer token in your IdP settings.
“RootSession may not be assumed by root accounts”: You are signed in as root. Sign in as an IAM or SSO user instead to use AssumeRoot or Root access management.
Cost Explorer access denied: Enable “IAM user and role access to Billing information” as root on the management account (see Billing Access section above).
Can’t sign in to member account as root: Expected behavior with centralized root access enabled. Use SSO or Switch Role with OrganizationAccountAccessRole instead.

Overview

Three AWS Sign-In Methods

IAM Users vs Identity Center Users

Recommended Daily Setup

Step 1: Create AWS Organizations

Via AWS Console

Via AWS CLI

Step 2: Create Organizational Units (OUs)

Via AWS Console

Via AWS CLI

Step 3: Create or Invite Member Accounts

Option A: Create a New Account

Option B: Invite an Existing Account

Move Accounts to OUs

Step 4: Enable IAM Identity Center (SSO)

Via AWS Console

Via AWS CLI

Step 5: Choose an Identity Source

To Change Identity Source (Console)

Step 6: Create Users and Groups

Create a Group

Create a User

Via AWS CLI

Step 7: Create Permission Sets

Via AWS Console

Via AWS CLI

Session Duration Guidance

Step 8: Assign Users/Groups to AWS Accounts

Via AWS Console

Via AWS CLI

Step 9: Configure the AWS Access Portal

Step 10: Enable MFA

Step 11: Set Up CLI/SDK Access (Optional)

Configure AWS CLI with SSO

Example ~/.aws/config

Onboarding Checklist for New Accounts

Useful CLI Commands Reference

Centralized Root Access

Can’t Assume Root / Access Denied

Available Privileged Root Actions

Accessing Member Accounts Without Root

Enabling Billing Access for Non-Root Users

How to Enable (One-Time, As Root)

Troubleshooting