Centralized Identity Management with IAM Identity Center
Specification & Description
Deploy AWS IAM Identity Center as the sole human access mechanism for all landing zone accounts, integrated with an external IdP, and enforce via SCP that direct IAM user creation and console access are blocked in member accounts.
Technical Specifications
IAM Identity Center is enabled in the Management account and applies organization-wide. It serves as the single control plane for human identity: users authenticate through the corporate IdP (Entra ID, Okta, Google Workspace) via SAML 2.0 or SCIM provisioning, are assigned to permission sets that define scoped IAM policies per account, and access accounts through the AWS access portal without long-lived credentials. This control mandates three things.
- Identity Center is active with an external IdP connected - the built-in directory is not acceptable for production landing zones.
- All central accounts (Management, Log Archive, Audit) have permission set assignments covering at least read-only and administrator tiers with MFA enforced at the Identity Center level.
- SCP prevents the creation of IAM users, login profiles, and access keys in member accounts, closing the bypass path that would otherwise allow teams to circumvent Identity Center. Break-glass IAM users in the Management account are the only permitted exception and must be documented under the exceptions section of AWS-IAM-001.
Security Rationale
Long-lived IAM user credentials - passwords and access keys - are the most common credential-based attack vector in AWS. Identity Center eliminates them for human access: sessions are short-lived, MFA is enforced centrally, and access is revoked by removing the IdP group assignment rather than hunting for individual IAM users across dozens of accounts. The audit trail in CloudTrail is attributed to the federated identity rather than a shared IAM user, making incident investigation significantly more precise.
Policy Exceptions (2)
Break-glass IAM users in the Management account are permitted as an emergency fallback when Identity Center or the IdP is unavailable. These must have no active access keys, must require MFA, must be documented in AWS-IAM-001, and must be audited monthly.
Service accounts requiring long-lived programmatic credentials (e.g. CI/CD pipelines not yet migrated to OIDC) may retain IAM users with access keys but must not have a login profile enabled. These are exempt from the SCP via the LandingZoneAdminRole carve-out and require documented approval renewed annually.
Operational & Implementation Notes
IAM Identity Center cannot be enabled via AWS CLI - the initial activation requires the Console or a CloudFormation stack set. Subsequent configuration (permission sets, assignments) is fully API-driven. The sso-admin API namespace is used for administration; the identitystore API namespace is used for user and group lookup. Identity Center is a global service deployed to a single home region - all API calls must target that region regardless of where member accounts are located. The SCP carve-outs for LandingZoneAdminRole and BreakGlassRole must reference the exact role names used in your organization; wildcards in ArnNotLike apply to the account segment only (arn:aws:iam::*:role/Name matches any account). Azure AD is now named Microsoft Entra ID - update IdP documentation accordingly.