Identity and Access Management Architecture

The Problem This Blueprint Solves

Your AWS accounts use local IAM users with long-lived access keys. The "admin" user has been shared among 8 engineers. Three former employees still have active credentials because nobody ran an access review. Root account access keys exist for "automation" purposes, MFA is optional, and your last audit found 47 IAM policies with Action: * on Resource: *. You are one compromised credential away from a catastrophic breach.

This blueprint is the identity architecture I implemented at a federal contractor managing 1,200 users across 85 AWS accounts, achieving FedRAMP and SOC 2 compliance for identity controls with zero standing administrative access and full audit trails for every privileged action.

What You Get

• Architecture diagrams — Identity federation flow, permission set hierarchy, SSO authentication sequence, service account management model, and access review automation pipeline (Draw.io)
• Terraform modules — IAM Identity Center (SSO) configuration, permission sets mapped to job functions, SCIM provisioning from Okta/Azure AD, cross-account role assumption chains, and SCP guardrails preventing IAM anti-patterns
• RBAC design — Permission set definitions for 8 standard job functions (Developer, DevOps, DBA, Security, Finance, Auditor, Platform Admin, Break-Glass), each scoped to least-privilege for their function
• Operational procedures — Onboarding/offboarding checklist, quarterly access review procedure, break-glass emergency access protocol, and access key rotation automation

Key Architecture Decisions

• IAM Identity Center over per-account IAM users — IAM users require separate credentials per account, have no central lifecycle management, and access reviews must query every account individually. Identity Center provides one credential set, federated from your corporate IdP, with centralized permission management and automatic deprovisioning when the IdP account is disabled.
• SCIM provisioning over manual group assignment — Manual SSO group management means someone must remember to add the new DBA to the DBA permission set. SCIM synchronization from Okta or Azure AD means group membership in your IdP automatically maps to AWS permission sets. HR offboards someone in Okta, AWS access revokes within minutes.
• Permission boundaries on all developer roles — Permission sets grant access, but permission boundaries define the maximum possible access. Even if a developer creates an IAM role in their sandbox account, the permission boundary prevents that role from exceeding the developer's own access level. This prevents privilege escalation through IAM role creation.
• SCPs to prevent IAM anti-patterns organization-wide — SCPs deny: creating IAM users with console access, creating access keys for root, disabling CloudTrail, and leaving S3 buckets public. These organization-level guardrails make insecure configurations impossible regardless of individual account permissions.

Who This Blueprint Is For

• Security Engineers centralizing identity management across multiple AWS accounts
• Cloud Architects replacing IAM users with federated identity
• Compliance teams implementing SOC 2 or FedRAMP identity controls
• IT Administrators managing AWS access for growing engineering organizations

Your First 48 Hours

Enable IAM Identity Center in your management account and configure SAML federation with your corporate IdP (Okta, Azure AD, or Google Workspace) using the provided Terraform module. Create the "Developer" permission set and assign it to a test group. Verify that a test user can SSO into a target account with only the permissions defined in the permission set. On day two, enable SCIM provisioning and verify that adding a user to the IdP group automatically grants AWS access, and removing them revokes it within 15 minutes.

Limitations and Trade-offs

IAM Identity Center supports one identity source — you cannot federate from Okta and Azure AD simultaneously. Permission sets have a maximum of 10 managed policies and one inline policy; complex permission requirements may need multiple permission sets per role. SCIM provisioning has eventual consistency — group membership changes take 5-15 minutes to propagate. Break-glass access (direct root login) bypasses all SSO controls and must be tightly governed with hardware MFA tokens stored in a physical safe. The blueprint includes the break-glass procedure but implementing physical security for root credentials is outside scope.