IAM Identity Center, Federation, and Temporary Credentials

IAM Identity Center, federation, and temporary credentials solve one AWS identity problem: users and workloads need access to many accounts, but long-lived IAM user keys are hard to govern, rotate, and audit. The outcome is a sign-in and credential flow where an external identity, a permission set, or a trusted workload is exchanged for a short-lived AWS role session.

In this Identity and Security section, the important AWS skill is not just creating a role. It is understanding which system authenticates the principal, which policy authorizes the action, which session name appears in logs, and when the credential automatically expires. That is the difference between a cloud estate that can be investigated and one that accumulates invisible access.

Purpose and Outcome

IAM Identity Center is the AWS service commonly used to centralize human access to AWS accounts. It can use its built-in identity store or connect to an external identity provider. Users sign in once, choose an assigned AWS account and role-like permission set, and receive temporary credentials for the account. Federation is the broader pattern: AWS trusts identity assertions or tokens from another system instead of storing the user password in IAM. AWS Security Token Service, or STS, issues the temporary access key, secret access key, and session token used by the AWS CLI, SDKs, and console.

The practical outcome is least-privilege, time-limited access. A finance analyst can get read-only billing access in the management account. A platform engineer can get administrator access in a sandbox but only network operations permissions in production. A CI job can exchange an OpenID Connect token for a deploy role without storing an AWS secret in the pipeline.

How the Mechanism Works

There are three separate decisions in the flow. First, authentication proves who or what the principal is. IAM Identity Center may authenticate the person directly or rely on an external identity provider using SAML. A workload federation flow may rely on an OpenID Connect token from a system such as a CI platform. Second, authorization maps that identity to an AWS permission boundary. In IAM Identity Center this mapping is an account assignment: principal, AWS account, and permission set. For workload federation it is usually an IAM role trust policy plus identity policies attached to the role. Third, STS creates the role session and credentials with an expiration time.

IAM Identity Center permission sets are templates. When assigned to an account, AWS provisions IAM roles and policies into that target account. The role name is AWS-managed, but the idea is familiar: a user does not directly own permissions in every account. Instead, the user is allowed to start a session in an account-specific role whose permissions come from the permission set. Permission sets can contain AWS managed policies, customer managed policies, inline policies, permissions boundaries, and session duration settings.

Temporary credentials always contain a session token in addition to an access key ID and secret access key. That token is mandatory because the credentials represent an STS session rather than a permanent IAM user. CloudTrail records the assumed role ARN, session issuer, source identity when configured, and request details. For incident response, the session name and identity provider mapping matter as much as the policy document.

Configuration Anatomy

A working design has four visible pieces: the identity source, assignments or trust policy, permissions, and client profile. The identity source answers who the user is. The assignment or trust policy answers whether that identity may start the AWS session. The permissions answer what the session may do after it starts. The client profile tells local tools how to request and refresh the temporary credentials.

For human access with IAM Identity Center, the AWS CLI profile stores a start URL, an Identity Center region, an account ID, and a role name. The CLI opens a browser sign-in flow, caches the Identity Center token locally, and requests role credentials when commands run.

[profile audit-readonly]
sso_start_url = https://example.awsapps.com/start
sso_region = us-east-1
sso_account_id = 111122223333
sso_role_name = AuditReadOnly
region = us-east-1
output = json

This is a configuration fragment, not a secret. It does not contain AWS access keys. The expected behavior is that aws sts get-caller-identity --profile audit-readonly returns an assumed role identity after browser sign-in, and later fails when the session expires until the user signs in again.

Worked Example 1: Human Console and CLI Access

Start with a central security team assigning a developer to a sandbox account through IAM Identity Center. The permission set grants read-only access plus limited CloudWatch Logs permissions. The developer uses the AWS access portal to open the console or uses an AWS CLI SSO profile.

set -euo pipefail

aws sso login --profile audit-readonly
aws sts get-caller-identity --profile audit-readonly --output json

The deterministic part is the shape of the response: it contains UserId, Account, and Arn. The ARN will be an assumed role ARN for the selected account, not an IAM user ARN. If the assignment is removed, the next credential request fails even if an old profile remains on the laptop. If the STS credentials are already issued, they remain usable only until their expiration.

Worked Example 2: SAML Federation to a Role

In a SAML federation design, the identity provider authenticates the user and sends a signed SAML assertion to AWS. The IAM role trust policy decides whether assertions from that SAML provider may call sts:AssumeRoleWithSAML. A common safety condition is the SAML audience, which ensures the assertion is intended for AWS sign-in.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:saml-provider/ExampleIdP"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}

Expected behavior is binary: a valid assertion from the named SAML provider can be exchanged for role credentials, while an assertion from another provider or for another audience is denied. The permissions still come from the role policies, not from the SAML document alone. SAML proves and carries identity attributes; IAM policies authorize AWS API actions.

Worked Example 3: OIDC Workload Federation

For automated delivery, avoid static AWS keys in the CI system. With OIDC federation, the pipeline receives a signed token from its own platform and calls sts:AssumeRoleWithWebIdentity. The role trust policy should restrict issuer, audience, and subject so only the intended repository, branch, environment, or workflow can assume the role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:example-org/example-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

The expected output of a successful exchange is temporary credentials with an expiration. The important design choice is the sub condition. If it is too broad, a different repository or branch may deploy. If it is too narrow, legitimate pipeline runs fail with an access denied error. Match it to the release process you actually want to authorize.

Design Choices and Trade-Offs

Use IAM Identity Center for workforce access across multiple AWS accounts because it centralizes assignment and improves offboarding. Use direct role federation when a specific external identity provider or workload token must exchange directly with STS. Use IAM roles for AWS services when the workload runs inside AWS, such as an EC2 instance profile, Lambda execution role, or ECS task role.

Shorter session durations reduce the time a stolen credential can be used, but they can interrupt long operations and require better refresh behavior in tools. Longer sessions reduce friction but increase exposure. Broad permission sets are simpler to administer but weaker for investigation and separation of duties. Many narrowly scoped permission sets are safer but require naming discipline and lifecycle management.

For multi-account AWS design, prefer assignments that follow job function and environment. A production administrator permission set should be distinct from a sandbox administrator permission set. Billing, audit, incident response, database operations, and network operations usually deserve different permission sets because they imply different evidence trails and approval paths.

Failure Modes and Troubleshooting

Symptom: the CLI says the SSO session is invalid or expired. Cause: the cached Identity Center token or STS role credentials expired. Diagnostic steps: run aws configure list --profile audit-readonly, then run aws sso login --profile audit-readonly. Correction: sign in again and verify with aws sts get-caller-identity.

Symptom: the user signs in but does not see the expected AWS account or permission set. Cause: the account assignment is missing, assigned to the wrong group, or not provisioned. Diagnostic steps: check the IAM Identity Center assignment for the exact user or group, account ID, and permission set. Correction: add or repair the assignment and reprovision the permission set to the account.

Symptom: a federated workload receives AccessDenied during AssumeRoleWithWebIdentity. Cause: the OIDC token claims do not match the role trust policy. Diagnostic steps: inspect the token issuer, audience, and subject in the CI run, then compare them with the trust policy conditions. Correction: update the trust policy to match the intended claim values, keeping branch and repository restrictions as narrow as practical.

Symptom: role assumption succeeds, but an AWS API call is denied. Cause: the trust policy allowed session creation, but the identity policy, permissions boundary, service control policy, or resource policy denies the action. Diagnostic steps: identify the assumed role ARN in CloudTrail, then evaluate the requested action, resource ARN, and all applicable policy layers. Correction: change the narrowest policy layer that should authorize the action.

Security, Reliability, and Performance Implications

Temporary credentials reduce blast radius because they expire automatically and can be scoped to a session. They do not remove the need for least privilege. A short-lived administrator session is still administrator access. Protect the identity provider, require strong authentication for workforce users, and log role assumption events. Use meaningful session names and source identity where available so CloudTrail can link activity back to a person or workload.

Reliability depends on the identity path. If the external identity provider or browser sign-in flow is unavailable, new sessions cannot start. Existing STS credentials may continue until expiration. For break-glass access, use tightly controlled emergency roles with monitored use, documented approval, and tested recovery steps. Performance is rarely limited by STS for normal use, but high-volume automation should cache credentials until near expiration instead of requesting new credentials for every API call.

Hands-On Lab

Prerequisites: an AWS account in an organization, permission to administer IAM Identity Center or a delegated admin account, AWS CLI installed, and a test user or group. Use a sandbox account, not production.

  1. Create or choose a test group named SandboxAudit in the IAM Identity Center identity source.
  2. Create a permission set named AuditReadOnly with read-only permissions and a session duration appropriate for a lab.
  3. Assign the SandboxAudit group to the sandbox account with the AuditReadOnly permission set.
  4. Configure an AWS CLI profile for the assigned account and role name.
  5. Run the login and identity verification commands from the first example.
  6. Attempt a read action such as listing S3 buckets, then attempt a write action such as creating a bucket with a disposable name.

Verification: the identity command should show the sandbox account ID and an assumed role ARN. The read action should succeed if the permission set includes it. The write action should fail with access denied, proving the session is not administrative.

Cleanup: remove the account assignment, delete the lab permission set if it is not reused, remove the test user from the group, and delete the local CLI profile entry. Confirm a new aws sso login can no longer obtain the same account role.

Assessment Exercises

  1. A developer can assume a production role after moving teams. Which objects would you inspect first: identity source membership, IAM Identity Center account assignments, role policies, or CloudTrail? Explain the order.
  2. A CI deployment role trust policy allows any branch in a repository to assume the role. Rewrite the condition strategy so only the main branch or a protected environment can deploy.
  3. A user can start a session successfully but cannot read one encrypted S3 object. Name at least three policy or configuration layers that could cause the denial.
  4. Choose a session duration for production incident response access and justify the trade-off between operational continuity and credential exposure.
  5. Design a CloudTrail query or review process that links an AWS API change back to the federated human or workload that made it.

Summary

IAM Identity Center centralizes human access, federation lets AWS trust external identity systems, and STS turns that trust into temporary credentials. The durable design lesson is to separate authentication from authorization, scope role sessions narrowly, preserve useful audit identity, and test both successful access and expected denial. In AWS cloud engineering, this pattern is the foundation for secure multi-account operations without distributing permanent keys.