IAM and Identity Federation at Scale

When an enterprise operates 50 or more AWS accounts, identity becomes one of the most consequential architectural decisions. Every API call, console login, and cross-account resource access depends on a principal proving who they are and what they are allowed to do. Designing identity at this scale requires moving beyond account-local IAM users toward centralized federation, temporary credentials, and layered authorization. The SAP-C02 exam tests whether you can architect these systems end-to-end, selecting the right combination of IAM policy conditions, STS role assumption, SAML 2.0 federation, and AWS IAM Identity Center to enforce least privilege without creating operational bottlenecks.

This lesson progresses from advanced policy design through federation models to unified identity governance, establishing the foundation that AWS Organizations and Service Control Policies extend in the next lesson.

Enterprise identity challenges in multi-account AWS

Managing IAM users independently in each account creates three compounding problems. First, credential sprawl multiplies the attack surface because every long-lived access key is a potential breach vector. Second, operational overhead grows linearly as teams must provision, rotate, and decommission users across every account. Third, audit complexity explodes because CloudTrail logs must be correlated across accounts to reconstruct a single user’s activity.

The AWS-preferred architecture replaces this anti-pattern with a layered identity stack that separates authentication, authorization, and credential management. IAM policies use condition keys to enforce context-aware authorization at the resource level, while AWS STS issues temporary credentials through role assumption, eliminating the need for long-lived access keys. SAML 2.0 federation integrates enterprise directories for workforce authentication, and web identity federation supports customer-facing applications through OIDC providers. AWS IAM Identity Center centralizes access management across accounts. Together, these components form a unified identity architecture where authentication is centralized, authorization is granular, and credentials are short-lived and secure.

Understanding how these layers interact is essential before examining each one in detail, starting with the policy evaluation engine that governs every authorization decision in AWS.

Advanced IAM policy design with conditions

Every AWS API request passes through the IAM policy evaluation engine, which applies a strict precedence hierarchy. An explicit deny in any applicable policy always wins. If no explicit deny exists, the engine looks for an explicit allow across all applicable policies. If no allow is found, the request is implicitly denied. This evaluation runs across identity-based policies, resource-based policies, permission boundaries, session policies, and Service Control Policies simultaneously.

Condition keys for context-aware access control

Condition keys transform static allow/deny statements into dynamic, context-sensitive controls. The following global condition keys appear frequently in SAP-C02 scenarios.

• aws:PrincipalTag enables attribute-based access control (ABAC)an authorization model where access decisions are driven by tags on principals and resources rather than by enumerating individual role permissions. A single policy can grant access to any resource whose department tag matches the caller’s department tag.

• aws:RequestTag enforces tagging standards by requiring that resources created through API calls carry specific tag keys and values.

• aws:MultiFactorAuthPresent restricts sensitive operations to sessions authenticated with a second factor, preventing compromised passwords from enabling destructive actions.

• aws:SourceVpc and aws:SourceIp constrain API calls to originate from approved network boundaries, adding a network-layer authorization check on top of identity verification.

• aws:TokenIssueTime validates session age, enabling policies that force re-authentication after a defined window.

Policy variables such as ${aws:PrincipalTag/Department} allow a single policy to dynamically reference the calling principal’s attributes. Without variables, an organization with 10 departments would need 10 separate policies. With ABAC, one policy covers all departments, and adding a new department requires only tagging the new principals and resources correctly.

Permission boundaries and delegated administration

The distinction between identity-based policies and permission boundaries is a common SAP-C02 test point. Identity-based policies grant permissions. Permission boundaries define the maximum permissions a principal can receive, regardless of what identity-based policies allow. The effective permission is the intersection of both.

This enables a delegated administration pattern where a central security team attaches permission boundaries to developer roles. Developers can then create IAM roles and policies for their workloads, but those roles can never exceed the boundary. For example, a boundary might restrict all created roles to S3 and DynamoDB in us-east-1, preventing a developer from accidentally granting EC2 or IAM administrative access.

Attention: Permission boundaries do not grant permissions on their own. A principal with a boundary but no identity-based policy has zero effective permissions. The boundary only caps what identity-based policies can grant.

The following policy examples demonstrate ABAC conditions and a permission boundary in practice.

These policy patterns reduce role proliferation and enforce guardrails without requiring central teams to approve every individual permission change. Federation models build on this foundation by determining how principals authenticate before these policies evaluate their requests.

Federation models for enterprise authentication

Federation separates authentication from authorization. The identity provider (IdP) handles authentication, and AWS handles authorization through IAM roles and policies. Two fundamentally different federation patterns serve different populations.

SAML 2.0 workforce federation

SAML 2.0 is the standard protocol for integrating enterprise directories such as Active Directory, Okta, or Azure AD with AWS. The authentication flow proceeds through four stages. The user authenticates against the corporate IdP using existing enterprise credentials. The IdP generates a SAML assertion containing attributes such as group membership and department. The user’s browser or CLI submits this assertion to AWS STS through the AssumeRoleWithSAML API. STS validates the assertion against the trusted IdP configuration, maps SAML attributes to an IAM role, and returns temporary credentials scoped to that role’s permissions.

This flow means no AWS-specific passwords exist for workforce users. Credential life cycle, MFA enforcement, and account deactivation all remain in the enterprise directory, providing a single point of governance.

Web identity federation for customer applications

Customer-facing applications use a different pattern. Mobile and web application users authenticate through social identity providers such as Google, Facebook, or Apple, or through Amazon Cognito User Pools that provide managed sign-up and sign-in. The application receives an OIDC token from the provider and exchanges it through AssumeRoleWithWebIdentity or through Cognito Identity Pools for temporary AWS credentials. These credentials allow the application to access AWS resources like S3 or DynamoDB directly from the client.

Practical tip: The SAP-C02 exam frequently tests whether you can distinguish these two patterns. SAML 2.0 is for employees accessing the AWS console and APIs. Web identity federation is for end users of mobile and web applications accessing AWS resources through application code. Choosing the wrong federation type is a common distractor.

The following diagram illustrates both federation flows side by side.

Both federation models produce temporary credentials through STS, which also enables cross-account access patterns in multi-account architectures.

Cross-account access with AWS STS

Cross-account role assumption is the backbone of a multi-account security architecture. Instead of creating IAM users in every account, a principal in one account assumes a role in another account, receiving temporary credentials scoped to that role’s permissions.

Role assumption mechanics

Two policies govern every cross-account assumption. The trust policy on the target role specifies which principals (accounts, roles, or federated users) are allowed to assume it. The permissions policy on the target role defines what actions the assumed identity can perform. The calling principal must also have sts:AssumeRole permission in their own identity-based policy.

STS returns temporary credentials with a configurable duration, defaulting to one hour and extendable up to 12 hours for IAM roles. These credentials automatically expire, eliminating the risk of forgotten or leaked long-lived keys.

External IDs and the confused deputy problem

When a third-party service assumes a role in your account, a confused deputy attackA security vulnerability where a trusted service is tricked into acting on behalf of an unauthorized party by assuming a role it has legitimate access to but for the wrong customer becomes possible. External IDs solve this by adding a shared secret to the trust policy condition. The third party must present the correct external ID during role assumption, and because each customer provides a unique external ID, one customer cannot trick the service into accessing another customer’s account.

Session tags and session policies

Session tags are key-value pairs passed during AssumeRole that become part of the session’s principal tags. They enable ABAC across accounts without creating separate roles for each access pattern. For example, a central operations team can assume a single role in any account while passing a session tag indicating which project they are working on, and the target account’s resource policies can restrict access based on that tag.

Session policies are inline policies passed during role assumption that further restrict the assumed role’s permissions for a specific session. They are useful when a single role serves multiple use cases that require different permission scopes.

Note: Session policies can only restrict permissions, never expand them. The effective permissions are the intersection of the role’s identity policy, any applicable permission boundary, and the session policy.

The following table compares the STS API operations that produce temporary credentials.

Temporary credentials from STS are the AWS-preferred pattern for all access scenarios, whether internal workforce, customer applications, or third-party integrations. AWS IAM Identity Center automates much of this complexity for workforce identity.

AWS IAM Identity Center architecture

AWS IAM Identity Center is the recommended solution for managing workforce access across an AWS organization. It replaces the manual process of configuring SAML trust relationships and IAM roles in each account with a centralized assignment model.

Core components and deployment model

Identity Center operates through three interconnected components. The identity source connects to an external IdP through SAML 2.0 or SCIM provisioning, or uses a built-in directory for smaller deployments. Permission sets act as standardized templates containing the IAM policies that define what actions a user can perform. Finally, account assignments link specific users or groups to those permission sets within targeted AWS accounts, creating a matrix of who can access what and where.

When a permission set is assigned to an account, Identity Center creates an IAM role in that account with the defined policies. Users authenticate once through the Identity Center portal and see all accounts and roles available to them. Selecting an account and permission set triggers STS role assumption behind the scenes, delivering temporary credentials without the user managing any federation details.

Integration with AWS Organizations

Identity Center integrates natively with AWS Organizations, automatically discovering all member accounts. This eliminates the need to manually register accounts or maintain federation metadata per account. When a new account is created through Organizations, it immediately becomes available for permission set assignments.

The centralized model contrasts sharply with the anti-pattern of managing IAM users or SAML configurations independently in each account. That approach creates inconsistent access policies, duplicated administrative effort, and gaps in offboarding where a departed employee retains access in forgotten accounts.

Trade-offs in identity architecture

Choosing between Identity Center and account-level SAML federation involves a clear trade-off. Identity Center provides lower operational overhead, consistent permission deployment, and a unified audit trail through CloudTrail integration. Account-level SAML federation offers more granular control over individual trust relationships and may be necessary when accounts exist outside the organization’s boundary.

Practical tip: Identity Center permission sets support both AWS managed policies and custom inline policies. For exam scenarios, prefer managed policies for common access patterns and custom policies only when specific condition keys or resource restrictions are required.

Conclusion

Enterprise identity architecture on AWS follows a layered authorization model. IAM policies with condition keys and ABAC enforce fine-grained, context-aware access at the resource level. Permission boundaries constrain delegated administrators so they cannot exceed defined guardrails. STS temporary credentials with session tags and external IDs replace static keys for cross-account and third-party access. AWS IAM Identity Center unifies workforce authentication and permission management across the entire organization. In the next lesson on AWS Organizations and SCP design, these identity controls are complemented by Service Control Policies, which define the absolute maximum permissions any principal can exercise, regardless of what their IAM policies or permission sets allow.