8.1 AWS IAM Identity Center & Enterprise IdP Integration

8.1 AWS IAM Identity Center & Enterprise IdP Integration

Enterprise cloud environments span dozens or hundreds of AWS accounts across complex organizational hierarchies. Managing localized IAM users and static access keys in each discrete account creates severe administrative overhead, credential sprawl, inconsistent offboarding, and elevated compliance risk. AWS IAM Identity Center (the successor to AWS Single Sign-On) resolves these challenges by providing a centralized control plane for workforce authentication, federation, and multi-account access governance across an entire AWS Organization.

Understanding IAM Identity Center's architecture, permission set mechanics, external identity provider (IdP) integration via SAML 2.0 and SCIM, multi-factor authentication (MFA) enforcement, and administrative assignment models is essential for the AWS Certified Security – Specialty exam.

---

IAM Identity Center Architecture & Deployment Topologies

IAM Identity Center integrates natively with AWS Organizations. When enabled, it establishes a central identity gateway where administrators configure identity sources, define permission sets, and assign access to accounts and cloud applications (such as Salesforce, Slack, or custom SAML 2.0 applications).

Instance Types: Organization vs. Account Instances

IAM Identity Center supports two deployment models:

1. Organization Instance: The standard enterprise deployment mode enabled in the AWS Organizations management account or a delegated administrator account. It governs access across all member accounts in the organization, centralizes identity federation, and coordinates automated provisioning across the AWS multi-account estate.
2. Account Instance: An isolated instance scoped strictly to a single AWS account. Account instances are typically used for standalone accounts outside an organization or specialized testing environments. They cannot manage permissions across multiple AWS accounts.

Delegated Administration for Security Operations

By default, IAM Identity Center is enabled in the AWS Organizations management account. However, operational security best practices mandate restricting direct day-to-day access to the management account. AWS Organizations supports Delegated Administration for IAM Identity Center:

• The management account designates a dedicated member account (typically the Shared Services or Security Tooling account) as the delegated administrator.
• The delegated administrator can configure identity sources, manage users and groups, author permission sets, and manage account assignments across the organization.
• Certain critical root-level actions—such as delegating or removing administrator status, or deleting the IAM Identity Center instance—remain restricted to the management account.

---

Multi-Account Permission Sets & Ephemeral Role Provisioning

A Permission Set is a collection of administrator-defined IAM policies that determine what actions a user or group can perform in an assigned AWS account. Rather than defining policies inside each individual account, security administrators manage permission sets centrally within IAM Identity Center.

Loading diagram...

How Permission Sets Work Under the Hood

When a permission set is assigned to a user or group for a specific target AWS account, IAM Identity Center automatically provisions an IAM role in that target account:

• Role Naming Convention: The provisioned role is named using the pattern AWSReservedSSO_<PermissionSetName>_<UniqueSuffix> (for example, AWSReservedSSO_SecurityAuditor_9c8b7a6d5e4f3a21).
• Trust Policy: The role's trust policy establishes a trust relationship with the IAM SAML identity provider (AWSSSO_..._DO_NOT_DELETE) provisioned in the target account by IAM Identity Center. The trust policy requires the sts:AssumeRoleWithSAML action.
• Ephemeral Credentials: When a workforce user logs in via the AWS access portal and selects an account, IAM Identity Center initiates a SAML assertion to the target account, which calls STS AssumeRoleWithSAML to vend temporary security credentials (AccessKeyId, SecretAccessKey, SessionToken).

Composition of a Permission Set

A permission set can incorporate four distinct policy types to enforce defense-in-depth:

Session Duration Configuration

Administrators configure the Session Duration on each permission set:

• Allowed values range from 1 hour to 12 hours (default is 1 hour). IAM Identity Center creates the provisioned roles with a 12-hour maximum session duration and enforces the permission set value.
• When a user assumes the role in the target account via the AWS Management Console or AWS CLI v2, the temporary STS credentials expire when the configured duration elapses.
• If a user needs to switch roles or their session expires, they must re-authenticate or re-select the account in the AWS access portal.

RelayState and Console Landing Configuration

Permission sets support a RelayState redirect URL. This parameter specifies the exact console landing page users are routed to upon assuming the role. For example, setting the RelayState to https://console.aws.amazon.com/guardduty/home immediately directs security analysts into the GuardDuty console rather than the default AWS Management Console home dashboard, streamlining operational workflows.

---

Identity Source Configuration & SAML 2.0 Federation

IAM Identity Center provides three distinct options for its underlying identity source:

1. Built-in Identity Center Directory: Users and groups are created and maintained directly within IAM Identity Center. Suitable for small environments or initial proof-of-concept deployments, but lacks automated enterprise identity lifecycle management.
2. Active Directory via AWS Directory Service: Connects to an on-premises Microsoft Active Directory (via AD Connector) or an AWS Managed Microsoft AD instance. Users authenticate using their corporate AD credentials.
3. External SAML 2.0 Identity Provider (IdP): Connects to modern enterprise identity providers such as Microsoft Entra ID (formerly Azure AD), Okta, PingFederate, CyberArk, or Google Workspace.

Loading diagram...

SAML 2.0 Configuration Mechanics

When configuring an external SAML 2.0 IdP, a mutual metadata exchange establishes the trust relationship:

• IAM Identity Center Metadata: Provides the AWS Access Portal URL, the Assertion Consumer Service (ACS) URL (https://<region>.signin.aws.amazon.com/platform/saml/acs/<instanceId>), and the SAML Entity ID (Audience URI).
• IdP Metadata: The external IdP provides its Federation Metadata XML document, containing its Issuer Entity ID, Single Sign-On Service URL, and the X.509 public signing certificate used to cryptographically validate SAML assertions.
• Subject NameID Mapping: The SAML assertion's Subject NameID attribute must map to a unique user attribute in the IAM Identity Center identity store (typically email or username). If the assertion's NameID does not match an existing user in IAM Identity Center, authentication fails with an Unauthorized error.

---

SCIM v2.0 Automated User & Group Provisioning

While SAML 2.0 handles authentication (verifying who the user is at login), it does not create, update, or remove users within the AWS identity store ahead of time. Without automated provisioning, administrators would have to manually recreate every user and group in IAM Identity Center.

SCIM (System for Cross-domain Identity Management) v2.0 is an open standard protocol for automated out-of-band identity lifecycle synchronization.

How SCIM Operates

1. SCIM Activation: The administrator enables automatic provisioning in IAM Identity Center, which generates a SCIM Endpoint URL (https://scim.<region>.amazonaws.com/<instanceId>/v2/) and an Access Token (bearer token).
2. IdP Configuration: In the external IdP (e.g., Microsoft Entra ID or Okta), the administrator inputs the SCIM endpoint and bearer token into the enterprise application provisioning settings.
3. Continuous Push Synchronization: The IdP acts as the SCIM client. Whenever an employee is hired, updated, or reassigned to a security group in the IdP, the IdP sends RESTful HTTPS API requests (POST, PUT, PATCH, DELETE) to the IAM Identity Center SCIM endpoint.
4. Deprovisioning and Offboarding: When an employee leaves the company and their account is disabled or deleted in Entra ID or Okta, the IdP sends an immediate SCIM PATCH request setting active: false or a DELETE request. The user is instantly disabled in IAM Identity Center, terminating their ability to log into the AWS access portal and access any AWS accounts.

Important Architecture Fact: SCIM synchronizes user metadata (first name, last name, email, username, group memberships), but does NOT synchronize user passwords. Passwords remain securely held inside the corporate IdP. Authentication continues to occur via SAML 2.0 redirect.

---

Multi-Factor Authentication (MFA) Enforcement Policies

Enforcing robust Multi-Factor Authentication (MFA) is mandatory for enterprise cloud security. In IAM Identity Center, MFA can be configured at the external IdP layer, directly within IAM Identity Center, or both.

Identity Center Native MFA Enforcement Settings

When managing users directly or requiring step-up verification within AWS, IAM Identity Center supports three MFA enforcement configurations:

1. Always-On (Enforced): Users are prompted for MFA every time they authenticate to the AWS access portal. If a user does not have an MFA device registered, they are forced to register one during their first login.
2. Context-Aware (Adaptive): Evaluates user risk based on device status, IP address, and location. Prompts for MFA only when sign-in patterns deviate from normal baselines.
3. Never (Disabled): Relies entirely on the external IdP to enforce MFA before issuing the SAML assertion.

Supported MFA Factor Types

Exam Tip: For maximum phishing resistance, enterprise security architectures mandate FIDO2/WebAuthn security keys. Unlike virtual TOTP codes, FIDO2 credentials cryptographically validate the origin domain, defeating reverse-proxy phishing frameworks like Evilginx.

---

The Multi-Account Assignment Model

The IAM Identity Center assignment model governs how access is granted across accounts:

[Principal: User or Group]  -->  [Permission Set]  -->  [Target: AWS Account]

Best Practices for Assignment Governance

1. Assign to Groups, Never Individual Users: Assigning permission sets to individual user objects creates massive administrative drift. Best practice requires assigning permission sets strictly to synchronized SCIM groups (e.g., AWS-Prod-NetworkAdmins, AWS-Dev-Developers). User role mobility is managed entirely in the corporate IdP by adding or removing users from groups.
2. Assignments Are Per Account: Each assignment links a principal and a permission set to one AWS account. The console lets you select several accounts at once (for example, every account in an OU), but that creates individual account assignments; accounts added to the OU later receive nothing automatically. Automate new-account assignments with Control Tower Account Factory customizations, infrastructure as code, or an event-driven workflow that calls CreateAccountAssignment.
3. Permission Set Re-Provisioning: When an administrator modifies an existing permission set (e.g., attaching a new policy or adjusting the session duration), the change is not immediately live in target accounts. IAM Identity Center must execute a re-provisioning workflow that updates the provisioned IAM roles in all associated AWS accounts. In large organizations, re-provisioning can take several minutes.

---

Specialty Exam Pitfalls & Architectural Traps

1. The Missing Customer Managed Policy Trap: If you attach a Customer Managed Policy named CorporateComplianceGuardrail to a permission set and assign it to an account, provisioning will fail with an error if an IAM policy named CorporateComplianceGuardrail does not already exist inside that target AWS account. To use CMPs in permission sets, deploy the underlying IAM policies to all target accounts first using AWS CloudFormation StackSets.
2. SCIM Token Expiration: The SCIM access token generated by IAM Identity Center has a validity period of one year. If the token expires without being rotated in the external IdP provisioning portal, user synchronization silently fails: new employees will not appear in the AWS access portal, and terminated employees will retain access until manual intervention.
3. Account Moves Do Not Change Access: Because assignments belong to accounts, not OUs, moving an account to a different OU leaves its IAM Identity Center assignments in place. Security teams that expect OU moves to revoke or grant access must update the assignments themselves.
4. SCIM vs. SAML Responsibilities: Remember the strict separation of duties: SAML 2.0 handles user authentication at runtime; SCIM handles user and group provisioning out-of-band. SCIM cannot authenticate a user, and SAML cannot push group membership updates without an active user sign-in.