AWS IAM Identity Center: SSO and Permission Management at Scale

You’re managing 50 AWS accounts, each with its own set of IAM users, keys, and policies. One engineer leaves, and you spend a week tracking down every account where they had access. That’s the old way. IAM Identity Center kills that pain by giving you a single pane of glass for SSO and permission management. But here’s the catch: if you don’t design your permission sets and group structure carefully, you’ll trade one mess for another. I’ve seen teams accidentally grant admin access to hundreds of users because they used a single permission set with AdministratorAccess. This isn’t just about convenience—it’s about enforcing least privilege at scale without drowning in IAM policy sprawl. In this post, I’ll show you how to set up IAM Identity Center with production-grade permission sets, integrate with an external IdP, and avoid the common pitfalls that lead to security incidents.

Why IAM Identity Center Over Traditional IAM Users

Managing access for hundreds or thousands of users with individual IAM users is a nightmare. Password rotation, key management, and MFA enforcement become operational drag. IAM Identity Center (formerly AWS SSO) centralizes access management by connecting to your existing identity provider (IdP) like Okta, Azure AD, or Ping. It eliminates long-lived credentials by issuing temporary, role-based credentials via SAML 2.0 or OIDC. For organizations scaling beyond 50 users, the operational savings are immediate: no more shared keys, no more orphaned IAM users, and audit trails that actually make sense. The shift is from per-user IAM policies to permission sets applied to groups—a model that mirrors how your org already structures teams. If you're still creating IAM users for humans, you're doing it wrong.

#!/bin/bash
# Enable IAM Identity Center (requires AWS Organizations)
aws organizations enable-aws-service-access \
  --service-principal sso.amazonaws.com

# Create an Identity Center instance
aws sso-admin create-instance \
  --name "ProductionSSO"

# Output instance ARN for later use
INSTANCE_ARN=$(aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text)
echo "Instance ARN: $INSTANCE_ARN"

Connecting Your Identity Provider: SAML vs OIDC

Identity Center supports both SAML 2.0 and OIDC for connecting external IdPs. SAML is the mature, battle-tested protocol—most enterprise IdPs support it natively. OIDC is newer and simpler, but not all IdPs offer it. The choice matters for your token lifecycle: SAML assertions typically last 1 hour, while OIDC tokens can be refreshed. For most production setups, SAML is the safe bet. The integration involves exchanging metadata XML (SAML) or registering a client (OIDC). Once connected, users authenticate against your IdP, not AWS. This means password policies, MFA, and account lifecycle are managed centrally. A common failure mode is misconfigured attribute mapping—AWS expects specific claims like 'email' and 'name'. If your IdP sends different attribute names, authentication silently fails. Always test with a single user before rolling out.

#!/bin/bash
# Download SAML metadata from IdP (example: Okta)
curl -s -o /tmp/idp-metadata.xml \
  "https://your-org.okta.com/app/.../sso/saml/metadata"

# Create IAM Identity Center external identity provider
aws sso-admin create-identity-provider \
  --instance-arn "$INSTANCE_ARN" \
  --name "Okta" \
  --type SAML \
  --metadata-document file:///tmp/idp-metadata.xml

# Verify provider
aws sso-admin list-identity-providers \
  --instance-arn "$INSTANCE_ARN"

Permission Sets: The Building Blocks of Access Control

Permission sets are the core of IAM Identity Center's authorization model. They define what a user can do in an AWS account—essentially a managed IAM policy attached to a role. Unlike IAM roles, permission sets are reusable across accounts and groups. You create a permission set once (e.g., 'ReadOnlyAccess', 'PowerUserAccess') and assign it to groups for specific accounts. This decouples policy definition from assignment, enabling consistent access patterns. Permission sets support both AWS managed policies and custom inline policies. A common anti-pattern is creating overly broad permission sets (e.g., 'AdministratorAccess' for everyone). Instead, follow least privilege: start with read-only, then add specific actions. Permission sets also support session duration—default 1 hour, but you can extend up to 12 hours. Be cautious: longer sessions increase risk if credentials are compromised.

#!/bin/bash
# Create a permission set with custom policy
aws sso-admin create-permission-set \
  --instance-arn "$INSTANCE_ARN" \
  --name "S3ReadOnly" \
  --description "Read-only access to S3" \
  --session-duration "PT2H"

# Get the permission set ARN
PERMISSION_SET_ARN=$(aws sso-admin list-permission-sets \
  --instance-arn "$INSTANCE_ARN" \
  --query 'PermissionSets[?contains(@, `S3ReadOnly`)]' \
  --output text)

# Attach an AWS managed policy
aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn "$INSTANCE_ARN" \
  --permission-set-arn "$PERMISSION_SET_ARN" \
  --managed-policy-arn "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"

Group-Based Assignment: Mapping Teams to Accounts

Once you have permission sets, you assign them to groups for specific AWS accounts. This is where the model shines: you create groups in your IdP (e.g., 'Engineering', 'DataScience', 'Auditors') and map them to permission sets per account. For example, the 'Engineering' group gets 'PowerUserAccess' in the dev account but 'ReadOnlyAccess' in production. This granularity prevents accidental cross-account damage. The assignment process is asynchronous—it can take a few minutes to propagate. Always verify assignments using the AWS Console or CLI. A common mistake is assigning permission sets to individual users instead of groups. This defeats the purpose of centralized management and creates audit gaps. Use groups exclusively; if a user needs special access, create a temporary group or use just-in-time access features.

#!/bin/bash
# Assign permission set to a group for a specific account
GROUP_NAME="Engineering"
ACCOUNT_ID="123456789012"
PERMISSION_SET_ARN="arn:aws:sso:::permissionSet/ssoins-.../ps-..."

# Get group ID from Identity Store
GROUP_ID=$(aws identitystore list-groups \
  --identity-store-id "d-12345abcde" \
  --query "Groups[?DisplayName=='$GROUP_NAME'].GroupId" \
  --output text)

# Create account assignment
aws sso-admin create-account-assignment \
  --instance-arn "$INSTANCE_ARN" \
  --target-id "$ACCOUNT_ID" \
  --target-type AWS_ACCOUNT \
  --permission-set-arn "$PERMISSION_SET_ARN" \
  --principal-type GROUP \
  --principal-id "$GROUP_ID"

echo "Assignment created. Propagation may take a few minutes."

Automating Provisioning with AWS CloudFormation

Manual configuration of Identity Center doesn't scale. For production environments, you need Infrastructure as Code (IaC) to manage permission sets and assignments. AWS CloudFormation supports IAM Identity Center resources via the 'AWS::SSO::PermissionSet' and 'AWS::SSO::Assignment' resource types. However, note that CloudFormation cannot create groups—those must exist in your IdP or be created via the Identity Store API. A common pattern is to use a CloudFormation stack set to deploy permission sets across multiple accounts. This ensures consistency and auditability. One pitfall: CloudFormation does not support importing existing permission sets. If you've created them manually, you must recreate them via CloudFormation. Always version-control your permission set definitions and use change sets to review modifications before deployment.

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  ReadOnlyPermissionSet:
    Type: AWS::SSO::PermissionSet
    Properties:
      InstanceArn: !Ref SSOInstanceArn
      Name: ReadOnlyAccess
      Description: Read-only access for auditors
      ManagedPolicies:
        - arn:aws:iam::aws:policy/ReadOnlyAccess
      SessionDuration: PT2H

  AssignmentToProd:
    Type: AWS::SSO::Assignment
    Properties:
      InstanceArn: !Ref SSOInstanceArn
      PermissionSetArn: !Ref ReadOnlyPermissionSet
      TargetId: !Ref ProdAccountId
      TargetType: AWS_ACCOUNT
      PrincipalType: GROUP
      PrincipalId: !Ref AuditorGroupId

Parameters:
  SSOInstanceArn:
    Type: String
  ProdAccountId:
    Type: String
  AuditorGroupId:
    Type: String

Auditing Access with AWS CloudTrail and IAM Access Analyzer

With great power comes great auditability. IAM Identity Center integrates with CloudTrail to log all administrative actions—creating permission sets, assignments, and authentication events. For user activity, CloudTrail logs the role session created via Identity Center, but the user identity is recorded as the federated user ARN. To trace back to the original user, you need to correlate the 'sessionIssuer' field with the Identity Center user ID. This is non-trivial at scale. A better approach is to use IAM Access Analyzer to generate a policy that grants least privilege based on actual usage. Access Analyzer can analyze CloudTrail logs and suggest refined policies. Additionally, enable AWS Config rules to detect unused permission sets or overly permissive assignments. Regular audits prevent privilege creep and reduce blast radius.

#!/bin/bash
# Query CloudTrail for Identity Center events
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccountAssignment \
  --query 'Events[*].{Time:EventTime,User:Username,Event:EventName}' \
  --output table

# Get the user identity from a specific event
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventId,AttributeValue="example-event-id" \
  --query 'Events[0].CloudTrailEvent' \
  --output text | jq '.userIdentity'

Scaling with Multiple Accounts: Organization-Wide Strategies

In large organizations with hundreds of AWS accounts, managing assignments individually is impossible. Use AWS Organizations to structure accounts into OUs (Organizational Units) and apply service control policies (SCPs) as guardrails. Identity Center assignments can be applied at the OU level using AWS CloudFormation StackSets or custom automation. However, Identity Center does not natively support OU-level assignments—you must iterate over accounts. A scalable pattern is to use a central management account that runs a Lambda function to sync group assignments to all accounts in an OU. This function reads from a DynamoDB table that defines the desired state. Another approach is to use AWS Control Tower, which integrates with Identity Center and automates account provisioning and permission set assignments. Control Tower's Account Factory can create new accounts with pre-defined permission sets, ensuring every new account is compliant from day one.

import boto3
import os

def lambda_handler(event, context):
    sso_admin = boto3.client('sso-admin')
    org = boto3.client('organizations')
    instance_arn = os.environ['INSTANCE_ARN']
    
    # Get all accounts in a specific OU
    ou_id = os.environ['OU_ID']
    accounts = []
    paginator = org.list_accounts_for_parent(ParentId=ou_id)
    for page in paginator:
        accounts.extend(page['Accounts'])
    
    # Define desired assignments (from DynamoDB or config)
    assignments = [
        {'GroupId': 'group-id-1', 'PermissionSetArn': 'ps-arn-1'},
        {'GroupId': 'group-id-2', 'PermissionSetArn': 'ps-arn-2'}
    ]
    
    for account in accounts:
        for assignment in assignments:
            try:
                sso_admin.create_account_assignment(
                    InstanceArn=instance_arn,
                    TargetId=account['Id'],
                    TargetType='AWS_ACCOUNT',
                    PermissionSetArn=assignment['PermissionSetArn'],
                    PrincipalType='GROUP',
                    PrincipalId=assignment['GroupId']
                )
            except Exception as e:
                print(f"Failed for account {account['Id']}: {e}")
    return {'status': 'completed'}

Just-in-Time Access and Temporary Elevation

Permanent elevated access is a security risk. IAM Identity Center supports just-in-time (JIT) access through session duration limits and the ability to request temporary elevation. While Identity Center itself doesn't have a native JIT request workflow, you can integrate with third-party tools like Okta's JIT or build a custom solution using AWS Step Functions and Lambda. The pattern: a user requests elevated access via a Slack command or web portal, which triggers a Lambda that creates a temporary group membership in the IdP, assigns a high-privilege permission set, and sets a TTL. After the TTL expires, a cleanup Lambda removes the group membership. This ensures elevated access is time-bound and audited. Another approach is to use AWS IAM Roles Anywhere for temporary credentials, but that's outside Identity Center. For most use cases, limiting session duration to 1 hour and requiring MFA re-authentication is sufficient.

import boto3
import os
from datetime import datetime, timedelta

def lambda_handler(event, context):
    # Extract user and requested permission set from event
    user_email = event['user_email']
    permission_set_arn = event['permission_set_arn']
    account_id = event['account_id']
    duration_minutes = int(event.get('duration', 60))
    
    identitystore = boto3.client('identitystore')
    sso_admin = boto3.client('sso-admin')
    instance_arn = os.environ['INSTANCE_ARN']
    identity_store_id = os.environ['IDENTITY_STORE_ID']
    
    # Find user in Identity Store
    user = identitystore.list_users(
        IdentityStoreId=identity_store_id,
        Filters=[{'AttributePath': 'UserName', 'AttributeValue': user_email}]
    )
    if not user['Users']:
        return {'status': 'error', 'message': 'User not found'}
    user_id = user['Users'][0]['UserId']
    
    # Create temporary assignment (assuming a temporary group exists)
    # In practice, you'd add user to a group, then assign group to permission set
    # For simplicity, we assign directly to user (not recommended for production)
    sso_admin.create_account_assignment(
        InstanceArn=instance_arn,
        TargetId=account_id,
        TargetType='AWS_ACCOUNT',
        PermissionSetArn=permission_set_arn,
        PrincipalType='USER',
        PrincipalId=user_id
    )
    
    # Schedule cleanup (using EventBridge or Step Functions)
    cleanup_time = datetime.utcnow() + timedelta(minutes=duration_minutes)
    # ... schedule cleanup event ...
    
    return {'status': 'success', 'expires': cleanup_time.isoformat()}

Troubleshooting Common Identity Center Failures

Even with careful planning, Identity Center can fail in frustrating ways. The most common issue is 'AccessDenied' when trying to assume a role—often due to missing trust policy or incorrect permission set. Check that the permission set includes the necessary trust relationship (Identity Center automatically creates the role, but custom policies may override). Another frequent problem is session duration exceeded—users get kicked out after the default 1 hour. Extend the session duration in the permission set, but be aware that longer sessions increase risk. Authentication failures are usually due to IdP misconfiguration: expired SAML certificates, incorrect ACS URL, or attribute mapping errors. Use the 'aws sso-admin list-account-assignments' command to verify assignments. If a user can't see an account in the portal, they likely lack an assignment. Finally, CloudTrail is your best friend for debugging—look for 'CreateAccountAssignment' failures or 'AssumeRoleWithSAML' errors.

#!/bin/bash
# Check if a user has assignments for a specific account
USER_NAME="user@example.com"
ACCOUNT_ID="123456789012"
INSTANCE_ARN="arn:aws:sso:::instance/ssoins-..."
IDENTITY_STORE_ID="d-12345abcde"

# Get user ID
USER_ID=$(aws identitystore list-users \
  --identity-store-id "$IDENTITY_STORE_ID" \
  --query "Users[?UserName=='$USER_NAME'].UserId" \
  --output text)

# List assignments for the user
aws sso-admin list-account-assignments \
  --instance-arn "$INSTANCE_ARN" \
  --account-id "$ACCOUNT_ID" \
  --query "AccountAssignments[?PrincipalId=='$USER_ID']" \
  --output table

# Check CloudTrail for assume role errors
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithSAML \
  --query "Events[?contains(ErrorCode, 'AccessDenied')]" \
  --output table

Migration from IAM Users to Identity Center: A Phased Approach

Migrating from IAM users to Identity Center is a multi-phase project. Phase 1: Set up Identity Center and connect your IdP. Phase 2: Create permission sets that mirror existing IAM policies. Phase 3: Create groups and assign permission sets to a pilot account. Phase 4: Migrate users gradually—start with read-only access, then move to power users. Phase 5: Disable IAM users for human access. The biggest challenge is mapping existing IAM policies to permission sets. Use IAM Access Analyzer to generate policies based on actual usage. Another challenge is handling service-specific credentials (e.g., database passwords) that were stored in IAM users. Those should be migrated to AWS Secrets Manager. During migration, maintain a fallback: keep IAM users active but enforce a password change to force users to switch. Monitor CloudTrail for any IAM user activity after the cut-off date. The goal is zero IAM users for humans within a quarter.

#!/bin/bash
# Script to identify IAM users with console access
aws iam list-users --query 'Users[?PasswordLastUsed!=null].UserName' --output text | tr '\t' '\n' | while read user; do
  echo "User $user has console access. Check if they have SSO access."
  # Optionally, disable console password
  # aws iam update-login-profile --user-name $user --password-reset-required
  # Or delete the login profile
  # aws iam delete-login-profile --user-name $user
done

# List users with access keys older than 90 days
aws iam list-users --query 'Users[?CreateDate<`2024-01-01`].UserName' --output text | tr '\t' '\n' | while read user; do
  echo "User $user has old access keys. Consider rotating or deleting."
done

Advanced: Cross-Account Access with Identity Center and SCPs

Identity Center can be combined with Service Control Policies (SCPs) to enforce guardrails across all accounts. For example, you can create an SCP that denies access to sensitive services (e.g., deleting CloudTrail trails) unless the request comes from a specific role. This adds a layer of defense even if a permission set is overly broad. Another advanced pattern is using Identity Center for cross-account access without assuming a role in the target account—instead, users authenticate once and can switch between accounts in the AWS Console. This is enabled by default. For programmatic access, you can use the AWS CLI with SSO tokens. The 'aws sso login' command caches credentials in ~/.aws/sso/cache. For automation, you can use the 'credential_process' in the AWS config file to fetch credentials programmatically. This eliminates the need for long-lived access keys even for CI/CD.

[profile dev]
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_region = us-east-1
sso_account_id = 123456789012
sso_role_name = PowerUserAccess
region = us-east-1
output = json

[profile prod]
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_region = us-east-1
sso_account_id = 098765432109
sso_role_name = ReadOnlyAccess
region = us-west-2
output = json

The Future: Identity Center and Permissions Boundaries

IAM Identity Center is evolving rapidly. One upcoming feature is support for permissions boundaries on permission sets. This will allow you to define the maximum permissions a permission set can grant, similar to IAM roles. This is a game-changer for multi-tenant environments where you want to delegate permission set creation to teams but enforce guardrails. Another trend is deeper integration with AWS IAM Access Analyzer for continuous policy refinement. As organizations adopt zero-trust models, Identity Center will likely support attribute-based access control (ABAC) natively. For now, you can implement ABAC by passing session tags from your IdP and using them in IAM policies. The key is to stay updated with AWS announcements and test new features in a staging environment before rolling out to production. The direction is clear: less static policies, more dynamic, context-aware access.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::data-lake-${aws:PrincipalTag/team}/*"
    },
    {
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalTag/role": "data-steward"
        }
      }
    }
  ]
}