14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies

Enterprise Workforce Identity: AWS IAM Identity Center

In modern multi-account enterprise architectures, managing static IAM users with long-term access keys inside individual member accounts is a critical anti-pattern. AWS IAM Identity Center (successor to AWS Single Sign-On) serves as the centralized identity hub, managing workforce access across all AWS accounts in an AWS Organization and third-party SaaS cloud applications.

Identity Provider (IdP) Federation: SAML 2.0 & SCIM

IAM Identity Center integrates natively with enterprise identity providers such as Okta, Microsoft Entra ID (formerly Azure AD), PingFederate, and CyberArk using two standardized protocols:

1. SAML 2.0 (Security Assertion Markup Language): Handles authentication. When a user signs into the AWS access portal, IAM Identity Center redirects the authentication request to the external IdP. Upon successful authentication (including enterprise MFA, device trust, and conditional access policies), the IdP issues a cryptographically signed SAML assertion back to Identity Center.
2. SCIM (System for Cross-domain Identity Management): Handles automated provisioning and lifecycle synchronization. The IdP periodically pushes user accounts, user attributes, group memberships, and account deactivations into IAM Identity Center via REST APIs. When an employee departs and is disabled in Okta or Entra ID, SCIM synchronizes the deactivation to IAM Identity Center. After propagation, the user cannot start new access, but SCIM does not revoke IAM role credentials that were already issued; session duration and explicit session-revocation procedures bound that residual access.

┌────────────────────────┐                   ┌───────────────────────────┐
│ Enterprise IdP (Okta / │ ─── SCIM Push ───>│  AWS IAM Identity Center  │
│  Microsoft Entra ID)   │ (Sync Users/Groups)│   (Central Org Account)   │
└───────────┬────────────┘                   └─────────────┬─────────────┘
            │                                              │
            │ SAML 2.0 Authentication                      │ Deploys Roles
            ▼                                              ▼
┌────────────────────────┐                   ┌───────────────────────────┐
│   Workforce Engineer   │ ─── AssumeRole ──>│ Member Accounts A, B, C   │
│ (Web Console / AWS CLI)│                   │ AWSReservedSSO_<Set>_<id> │
└────────────────────────┘                   └───────────────────────────┘

Permission Sets Architecture & Member Account Roles

A Permission Set is a collection of administrator-defined IAM policies that define the level of access users and groups have within targeted AWS accounts. When an administrator assigns a Permission Set and an identity group to an account:

• Automated IAM Role Provisioning: IAM Identity Center automatically deploys an IAM service-linked role named AWSReservedSSO_<PermissionSetName>_<random-hash> inside the target member account.
• Managed Trust Policy: The provisioned role contains a trust policy allowing federation from the IAM Identity Center instance.
• Policy Composition: A Permission Set can incorporate:
  • Predefined AWS Managed Policies (e.g., AdministratorAccess, ViewOnlyAccess).
  • Customer Managed Policies that exist in the target member account.
  • Inline Policies defined directly within the Permission Set in Identity Center.
  • Permissions Boundaries to constrain the maximum permissions granted by the set.
• Session Duration: Configurable from 15 minutes up to 12 hours (default: 1 hour).

---

Cross-Account Role Assumption with AWS STS

For machine-to-machine interactions, automated CI/CD deployment pipelines, and operational cross-account governance, AWS Security Token Service (STS) provides temporary, rotating security credentials through the AssumeRole API.

The Two-Way Reciprocal Trust Model

Cross-account role assumption requires explicit reciprocal configuration across both accounts:

1. Target Account (Account B - Trusting Account): The target role must have a Trust Policy (resource-based policy) that explicitly allows the principal in Account A to assume it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TrustAccountAPrincipal",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/CICDPipelineRole"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

1. Calling Account (Account A - Trusted Account): The calling entity (CICDPipelineRole) must possess an Identity Policy allowing it to call sts:AssumeRole targeting Account B's role ARN:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAssumeRoleInAccountB",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::222222222222:role/ProductionDeploymentRole"
    }
  ]
}

When sts:AssumeRole is invoked, STS returns temporary credentials consisting of an AccessKeyId, SecretAccessKey, SessionToken, and Expiration (valid from 15 minutes up to 12 hours depending on the role's maximum session duration).

---

Preventing Confused Deputy Attacks with sts:ExternalId

The Confused Deputy problem is a classic cross-account security vulnerability that arises when a customer grants a third-party multi-tenant SaaS provider (e.g., a SaaS monitoring, security scanning, or cost optimization tool) permission to assume an IAM role in the customer's account.

The Vulnerability Flow

1. Company X signs up with SaaS Vendor V. Vendor V tells Company X: "Create an IAM role trusting our AWS account (999999999999) so our scanner can analyze your environment."
2. Attacker A also signs up with SaaS Vendor V. Attacker A configures their scanner settings, but enters Company X's IAM Role ARN instead of their own.
3. Vendor V's backend assumes Company X's IAM role using its legitimate credentials. Because Company X's trust policy simply trusted Vendor V's account ARN, the request succeeds.
4. Attacker A receives all of Company X's sensitive infrastructure and operational data from Vendor V's console! Vendor V acted as a confused deputy.

The Architectural Solution: sts:ExternalId

To eliminate this vulnerability, the SaaS vendor must generate a unique, secret, cryptographically random identifier (External ID) for each customer tenant.

• When Company X configures their role trust policy, they mandate that the caller must supply this unique External ID using the sts:ExternalId condition key:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::999999999999:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "x-tenant-uuid-9876-5432-10fe-cba987654321"
        }
      }
    }
  ]
}

When Vendor V assumes the role on behalf of Company X, its backend includes the parameter --external-id x-tenant-uuid-.... If Attacker A attempts to pass Company X's role ARN, Vendor V will pass Attacker A's External ID, the condition evaluation fails, and STS immediately rejects the request.

---

Dynamic Ephemeral Scoping: STS Session Policies

In modern automated CI/CD pipelines, creating and maintaining distinct static IAM roles for hundreds of individual microservices and deployment stages creates severe administrative overhead and quickly approaches IAM service quotas.

STS Session Policies enable a powerful architectural pattern: Ephemeral Least-Privilege Scoping. An advanced session policy is an inline policy (or managed policy ARNs) passed as a parameter during the sts:AssumeRole API call:

aws sts assume-role \
    --role-arn arn:aws:iam::222222222222:role/GenericDeploymentRole \
    --role-session-name DeployOrdersServiceJob \
    --policy '{
        "Version": "2012-10-17",
        "Statement": [{
            "Effect": "Allow",
            "Action": ["ecs:UpdateService", "s3:*"],
            "Resource": [
                "arn:aws:ecs:us-east-1:222222222222:service/prod-cluster/orders-service",
                "arn:aws:s3:::prod-orders-assets/*"
            ]
        }]
    }'

Evaluation Mechanics of Session Policies

• The session policy does not grant any permissions independently.
• The temporary session's effective permissions are strictly the intersection of the role's identity policy and the dynamic session policy.
• A centralized CI/CD server in a Shared Services account can assume a single cross-account DeploymentRole across 50 target accounts, dynamically passing a session policy that restricts the resulting credentials strictly to the specific microservice, bucket, or cluster targeted by that individual pipeline execution.

---

STS Regional Endpoints vs. Global Endpoint & VPC PrivateLink