AWS Identity Center (SSO) Setup and Best Practices for Multi-Account Security

Why AWS Identity Center Matters

AWS Identity Center (formerly AWS SSO) is the recommended service for managing workforce access across multiple AWS accounts. Instead of creating IAM users in each account, Identity Center provides a single point of authentication that federates access across your entire AWS Organizations structure.

Without centralized identity management, organizations face:

1. Credential sprawl - IAM users with long-term access keys in every account
2. Inconsistent permissions - Different permission models across accounts
3. No unified audit trail - Difficult to answer "who has access to what"
4. Manual provisioning - Slow onboarding and dangerous offboarding gaps

Setting Up AWS Identity Center

Choosing an Identity Source

Identity Center supports three identity sources. For most organizations, connecting an external identity provider is the right choice.

# Check if Identity Center is already enabled in your organization
aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text

# List the current identity source configuration
aws sso-admin describe-instance \
  --instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef

# If using the built-in directory, create a user
aws identitystore create-user \
  --identity-store-id d-1234567890 \
  --user-name jsmith \
  --name '{"GivenName": "Jane", "FamilyName": "Smith"}' \
  --emails '[{"Value": "[email protected]", "Type": "Work", "Primary": true}]' \
  --display-name "Jane Smith"

Creating Permission Sets

Permission sets are templates that define what users can do when they assume a role in a target account. Each permission set becomes an IAM role in every account where it is provisioned.

{
  "PermissionSet": {
    "Name": "SecurityAuditor",
    "Description": "Read-only access to security services and IAM configuration",
    "SessionDuration": "PT4H",
    "ManagedPolicies": [
      "arn:aws:iam::aws:policy/SecurityAudit",
      "arn:aws:iam::aws:policy/ReadOnlyAccess"
    ],
    "InlinePolicy": {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "DenyDataAccess",
          "Effect": "Deny",
          "Action": [
            "s3:GetObject",
            "dynamodb:GetItem",
            "dynamodb:Query",
            "dynamodb:Scan"
          ],
          "Resource": "*"
        },
        {
          "Sid": "AllowSecurityTooling",
          "Effect": "Allow",
          "Action": [
            "access-analyzer:*",
            "guardduty:Get*",
            "guardduty:List*",
            "securityhub:Get*",
            "securityhub:List*",
            "inspector2:List*",
            "inspector2:Get*"
          ],
          "Resource": "*"
        }
      ]
    }
  }
}

This permission set grants broad read access for security auditing while explicitly denying access to actual data in S3 and DynamoDB. The 4-hour session duration is appropriate for audit work without being excessively long.

Session Duration Policies

Session durations should follow the principle of least privilege applied to time:

• Administrative access: 1-2 hours maximum
• Developer access: 4-8 hours for daily work
• Read-only/audit access: 4-12 hours
• CI/CD service accounts: 1 hour with automatic refresh

SAML and SCIM Integration

Configuring SAML with an External IdP

SAML 2.0 handles authentication, while SCIM handles automatic provisioning. Both are essential for a production setup.

When configuring SAML, your identity provider sends assertions containing user attributes. These attributes can be mapped to AWS session tags for attribute-based access control.

SCIM Provisioning

SCIM (System for Cross-domain Identity Management) automatically synchronizes users and groups from your IdP to Identity Center. This ensures that when someone leaves your organization and is disabled in your IdP, their AWS access is revoked within minutes.

Key SCIM considerations:

• Group-based assignment - Map IdP groups to permission sets rather than assigning individual users
• Conflict resolution - SCIM is the source of truth; manual changes in Identity Center will be overwritten
• Provisioning scope - Only sync groups that need AWS access, not your entire directory
• Rate limits - SCIM provisioning has API rate limits; large initial syncs should be staged

Attribute-Based Access Control (ABAC)

ABAC lets you write policies that grant access based on attributes (tags) rather than explicit resource ARNs. When combined with Identity Center, user attributes from your IdP become session tags in AWS.

# Example: ABAC policy for Identity Center permission set
# Users can only manage resources tagged with their department
Version: "2012-10-17"
Statement:
  - Sid: AllowEC2ManagementByDepartment
    Effect: Allow
    Action:
      - ec2:StartInstances
      - ec2:StopInstances
      - ec2:RebootInstances
      - ec2:TerminateInstances
    Resource: "*"
    Condition:
      StringEquals:
        "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"

  - Sid: AllowCreateWithDepartmentTag
    Effect: Allow
    Action:
      - ec2:RunInstances
      - ec2:CreateTags
    Resource: "*"
    Condition:
      StringEquals:
        "aws:RequestTag/Department": "${aws:PrincipalTag/Department}"
      ForAllValues:StringEquals:
        "aws:TagKeys":
          - Department
          - Environment
          - Name

  - Sid: DenyUntaggedResources
    Effect: Deny
    Action:
      - ec2:RunInstances
    Resource: "arn:aws:ec2:*:*:instance/*"
    Condition:
      "Null":
        "aws:RequestTag/Department": "true"

This policy ensures engineers can only manage EC2 instances tagged with their own department, and all new instances must carry a department tag. The ${aws:PrincipalTag/Department} variable is populated from the session tag that Identity Center propagates from your IdP.

ABAC Advantages Over Traditional RBAC

• Fewer permission sets - One policy scales across departments instead of one per team
• Self-service tagging - New projects get access automatically when tagged correctly
• Reduced admin overhead - No policy updates needed when teams or projects change
• Auditability - Tag-based access is easy to query and report on

Multi-Account Access Patterns

Account Assignment Strategies

Structure your account assignments around job functions, not organizational hierarchy:

• Platform team - Full admin on infrastructure accounts, read-only on workload accounts
• Application teams - Developer access to their team's accounts only
• Security team - SecurityAudit access across all accounts
• Finance team - Billing and cost explorer access to the management account

Emergency Access

Always maintain a break-glass procedure that bypasses Identity Center. Create a dedicated IAM user in the management account with MFA and a hardware token stored in a physical safe. This account should only be used when Identity Center or your IdP is completely unavailable.

Common Pitfalls

• Over-scoped permission sets - Avoid granting AdministratorAccess broadly; create role-specific permission sets
• Missing SCIM deprovisioning - If SCIM is not configured, terminated employees retain access until manually removed
• Ignoring session duration - Default 1-hour sessions cause friction; 12-hour sessions for admin access create risk
• Not using groups - Assigning permission sets to individual users does not scale and creates audit confusion
• Skipping MFA enforcement - Identity Center supports MFA; it should be mandatory for all users

Securing Identity Center with AccessLens

AWS Identity Center simplifies multi-account access management, but the complexity of permission sets, ABAC policies, and cross-account assignments creates blind spots. Misconfigured permission sets can grant unintended access across dozens of accounts simultaneously.

AccessLens helps secure your Identity Center deployment by providing:

• Permission set analysis that identifies overprivileged role assignments across your organization
• Cross-account access mapping that visualizes which users and groups can access which accounts and with what permissions
• Trust relationship graphing that reveals how Identity Center roles interact with resource-based policies in target accounts
• ABAC policy validation that checks whether tag-based policies are effectively restricting access
• Continuous monitoring that alerts you when permission sets are modified or new account assignments are created

Identity Center is the foundation of multi-account security, but it requires ongoing visibility to ensure your access model stays aligned with your security requirements.

Secure your Identity Center deployment with AccessLens and gain complete visibility into who can access what across your entire AWS organization.

Don't let the complexity of multi-account access management create security blind spots. Get the IAM visibility you need to maintain a strong security posture.