AWS IAM Identity Center for Enterprises: Architecture, Setup, and Security Hardening

Overview

AWS IAM Identity Center is AWS's workforce identity and access service for centrally managing user access to multiple AWS accounts and business applications. Enterprises use it to replace long-lived IAM users, standardize federated access, and enforce least privilege across AWS Organizations.

Its core purpose is to connect an identity source such as the built-in directory, Active Directory, or an external IdP, then map users and groups to AWS accounts and permission sets. This reduces credential sprawl, improves auditability with CloudTrail, and simplifies access lifecycle management for joiner, mover, and leaver processes.

Architecture

Core components include:

• IAM Identity Center instance in a management or delegated admin account
• Identity source: built-in directory, AWS Managed Microsoft AD, AD Connector, or external SAML/SCIM IdP
• AWS Organizations for account discovery and assignment
• Permission sets that translate to IAM roles in target accounts
• Applications integrated through SAML 2.0
• Audit services such as AWS CloudTrail and AWS Config

Deployment models:

• AWS-native: built-in directory with direct user/group management
• Hybrid enterprise: Active Directory as identity source
• Federated SaaS IdP: Microsoft Entra ID or Okta with SCIM provisioning

[User] ---- 1. sign-in ----> [External IdP]
[External IdP] ---- 2. SAML/SCIM ----> [IAM Identity Center]
[IAM Identity Center] ---- 3. assignment lookup ----> [AWS Organizations]
[IAM Identity Center] ---- 4. provision role ----> [Target AWS Account]
[Target AWS Account] ---- 5. temporary credentials ----> [User]
[CloudTrail] <---- 6. audit events ---- [IAM Identity Center]

Data flow is straightforward: the user authenticates with the enterprise IdP, IAM Identity Center resolves group membership and account assignments, then issues short-lived access through generated IAM roles in each assigned account.

Implementation Guide

1. Enable IAM Identity Center in the management account or configure delegated administration.
2. Integrate AWS Organizations and confirm all target accounts are visible.
3. Choose an identity source and configure SCIM if using Entra ID or Okta.
4. Create permission sets and assign them to groups.
5. Test portal sign-in and CLI access.

Exact CLI workflow:

aws sso-admin list-instances
aws identitystore list-users --identity-store-id d-1234567890
aws sso-admin list-permission-sets --instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef
aws sso-admin create-permission-set --instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef --name ReadOnlyOps --session-duration PT4H
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/ReadOnlyAccess
aws sso-admin create-account-assignment --instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef --target-id 123456789012 --target-type AWS_ACCOUNT --permission-set-arn arn:aws:sso:::permissionSet/ssoins-1234567890abcdef/ps-abcdef1234567890 --principal-type GROUP --principal-id 08d7e3c2-1111-2222-3333-444455556666
aws configure sso
aws sso login --profile prod-readonly

Recommended CLI profile:

[sso-session corp]
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_region = eu-west-1
sso_registration_scopes = sso:account:access

[profile prod-readonly]
sso_session = corp
sso_account_id = 123456789012
sso_role_name = ReadOnlyOps
region = eu-west-1
output = json

Code Examples

Example 1: Inline policy for a permission set

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:Describe*", "s3:ListAllMyBuckets", "cloudwatch:Get*"],
      "Resource": "*"
    }
  ]
}

Example 2: Terraform assignment pattern

resource "aws_ssoadmin_permission_set" "readonly" {
  instance_arn     = var.instance_arn
  name             = "ReadOnlyOps"
  session_duration = "PT4H"
}

resource "aws_ssoadmin_managed_policy_attachment" "readonly_attach" {
  instance_arn       = var.instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.readonly.arn
  managed_policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
}

Example 3: Python audit of assignments

import boto3
client = boto3.client("sso-admin")
instance_arn = "arn:aws:sso:::instance/ssoins-1234567890abcdef"
for ps in client.list_permission_sets(InstanceArn=instance_arn)["PermissionSets"]:
    print(ps)

Security Hardening

• Use external MFA in the upstream IdP and require phishing-resistant methods where possible.
• Prefer group-based assignments over direct user assignments for clean lifecycle control.
• Limit session duration by role sensitivity; for admin roles use PT1H or PT2H.
• Enable CloudTrail organization trails and monitor sso.amazonaws.com, identitystore.amazonaws.com, and signin.amazonaws.com events.
• Use customer-managed policies instead of broad AWS managed policies for privileged roles.
• Restrict delegated administration and protect the management account with SCPs.
• Ensure encryption at rest for related logs in S3 and KMS-backed CloudTrail destinations.

Comparison

Troubleshooting

Error 1: No assigned accounts

Log sample:

$ aws sso login --profile prod-readonly
There are no AWS accounts available to you.

Fix: Verify the group is provisioned through SCIM, the user is a member of that group, and the group has an account assignment for the target account and permission set.

Error 2: Access denied on assignment creation

Log sample:

An error occurred (AccessDeniedException) when calling the CreateAccountAssignment operation: User is not authorized to perform sso:CreateAccountAssignment

Fix: Run the command from the management or delegated admin account and grant sso:CreateAccountAssignment plus related identitystore read permissions.

Error 3: SCIM provisioning failure

Log sample:

2024-11-12T09:14:22Z scim.amazonaws.com ERROR RequestId=7f3d2f0a-9d5e-4d8e-bb3d-0e2c8d0a1f11 StatusCode=409 Message="Group displayName already exists"

Fix: Remove duplicate groups in the identity source, re-run provisioning, and ensure immutable object identifiers are mapped correctly.

Best Practices

Do

• Use AWS Organizations OUs to standardize access patterns by environment.
• Map job functions to permission sets, for example PlatformAdmin, SecurityAudit, and BillingReadOnly.
• Automate permission sets and assignments with Terraform or CI pipelines.
• Review unused assignments quarterly using CloudTrail and access reports.

Don't

• Do not create IAM users for workforce access except for controlled break-glass scenarios.
• Do not assign AdministratorAccess broadly to engineering groups.
• Do not manage production access with direct user assignments when groups are available.
• Do not ignore IdP deprovisioning tests; validate leaver workflows end to end.