Single Sign-On with AWS IAM Identity Center - Multi-Account Access Management
Achieve single sign-on for multi-account environments and control access levels to each account with permission sets. Covers external IdP integration and ABAC usage.
Overview of IAM Identity Center
IAM Identity Center (formerly AWS SSO) is a service that centralizes single sign-on and access management for multi-account environments. Users log in to the AWS access portal and access their assigned AWS accounts and applications with a single click. This eliminates the need to create IAM users in each individual account, fundamentally removing the security risk of scattered credentials. It is enabled from the Organizations management account or a delegated administrator account, applying access control across all accounts in the organization. Supported protocols include SAML 2.0 and OIDC, providing federated access to the AWS Management Console, CLI v2, SDK, and SAML-compatible third-party applications (Salesforce, Slack, GitHub, etc.). You sign in with an AWS Builder ID and configure connections to AWS accounts to centralize deployment target management.
Choosing an ID Source and External IdP Integration
IAM Identity Center supports three identity sources. The first is the Identity Center directory (built-in), suitable for small organizations or verification environments. The second is Active Directory (via AWS Managed Microsoft AD or AD Connector), allowing you to use on-premises AD as-is. The third is external IdP, delegating authentication via SAML 2.0 and executing automatic user and group provisioning via SCIM 2.0. Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, OneLogin, and Ping Identity support automatic synchronization via SCIM. Adding, removing, or changing group memberships in the IdP is immediately reflected in IAM Identity Center. Disabling a user in the IdP immediately revokes AWS access, eliminating security risks from forgotten account deletions during offboarding.
Permission Sets and Access Assignments
Permission sets are collections of IAM policies that can include AWS managed policies such as AdministratorAccess and ReadOnlyAccess, custom policies (written directly in JSON), and references to customer managed policies. A single permission set can contain up to 10 managed policies and 1 inline policy. When you assign a permission set to a user/group and account combination, the corresponding IAM role is automatically created when that user accesses the account. Permission boundaries can also be configured, constraining the ceiling of a permission set with an IAM policy to enforce the principle of least privilege. Access assignments are defined by the three-factor combination of permission set, AWS account, and user or group, and group-based assignments mean that adding or removing members from a group automatically updates their permissions.
ABAC and Session Management
IAM Identity Center supports attribute-based access control (ABAC), dynamically granting access permissions based on user attributes (department, job title, project, cost center). SAML attributes passed from the IdP are mapped to IAM session tags, and access is controlled by matching them against resource tags. For example, a user with department=engineering can access only S3 buckets tagged with department=engineering, enforced across accounts. Session duration is configurable per permission set from 1 to 12 hours, with short sessions (1 hour) for high-security environments and longer sessions (12 hours) for development. The AWS access portal provides one-click access to the management console or CLI, making it easy to switch between accounts. ```bash # AWS CLI v2 SSO profile configuration example (~/.aws/config) [profile dev-admin] sso_session = my-sso sso_account_id = 123456789012 sso_role_name = AdministratorAccess region = ap-northeast-1 [sso-session my-sso] sso_start_url = https://my-org.awsapps.com/start sso_region = ap-northeast-1 sso_registration_scopes = sso:account:access # Execute SSO login aws sso login --profile dev-admin ``` The CLI v2 sso login command launches a browser-based authentication flow, and after authentication completes, temporary credentials are automatically cached. This eliminates the need to manage long-term access keys, improving security. To deepen your practical knowledge of SSO authentication, specialized books on Amazon can be helpful.
Design Best Practices and Pitfalls
When designing permission sets, follow the principle of one permission set per job function, assigning multiple permission sets to a single user to achieve separation of duties. For example, give developers a DevOps permission set (for deployments) and a ReadOnly permission set (for auditing), assigning different permission sets for production versus development environments. A common pitfall is SCIM synchronization latency. There is a lag (typically seconds to minutes) between group changes in the IdP being reflected in Identity Center, during which access with old permissions may persist, so manual sync should be triggered for privilege escalation changes. Another consideration is delegated administrator setup. When operating Identity Center from an account other than the management account, you designate a delegated administrator account, but this account itself cannot have permission set assignments. Additionally, only one Identity Center instance can be enabled per Organization, and the region is fixed. In multi-region organizations, the home region selection affects access portal latency for all users.
Cognito Comparison and Other Authentication Approaches
IAM Identity Center and Cognito are both authentication services but target different user populations. IAM Identity Center is the authentication foundation for employees and developers accessing the AWS Management Console or CLI, while Cognito is an authentication and authorization service for end users (customers) of web/mobile applications. Cognito provides sign-up, social login, and token management, whereas IAM Identity Center specializes in federated access to AWS accounts. Other multi-account management approaches include creating IAM users per account (credentials scattered, high operational burden), cross-account IAM role AssumeRole (difficult to manage at scale with dozens of accounts), and third-party SSO products (requiring IdP configuration changes per account addition). IAM Identity Center resolves these challenges holistically through deep Organizations integration. CloudTrail integration also automatically records audit logs of who accessed which account and when.
IAM Identity Center Pricing
IAM Identity Center is free to use. There are no additional charges for the number of users, groups, or SSO sessions. Integration with external IdPs (Okta, Microsoft Entra ID, Google Workspace) via SAML/SCIM is also free. Costs depend on the usage fees of the AWS accounts and applications managed by Identity Center. Service quotas for Identity Center include a limit of 100,000 users per instance, 100,000 groups, 2,000 permission sets, and 50 permission set assignments per account. Enable IAM Identity Center across all Organizations accounts and retire direct IAM user creation to simultaneously improve security and operational efficiency.
Summary
IAM Identity Center is a free service that centralizes SSO and access management for multi-account environments. Choose from three identity sources (built-in directory, Active Directory, external IdP) based on your environment, and define access permissions by combining AWS managed policies and custom policies in permission sets. Use ABAC for dynamic permission assignment based on user attributes, and authenticate seamlessly from the terminal with CLI v2 SSO profiles. Design permission sets on a per-job-function basis, and understand the delegated administrator constraints and fixed-region behavior before proceeding with deployment.