Workforce Identity and Federation

What it is

Authentication proves who a caller is. For people who work with AWS, the modern pattern is to keep identities in one external or central directory and give them temporary access to accounts, instead of creating long lived IAM users in every account.

This page covers the options for workforce access: IAM Identity Center, direct federation with SAML (Security Assertion Markup Language) and OIDC (OpenID Connect), and directory services.

How it works

IAM Identity Center

AWS IAM Identity Center is the recommended way to give a workforce access to multiple AWS accounts and business applications. You connect an identity source, create permission sets, and assign users or groups to accounts with those permission sets.

• Identity source. The built in Identity Center directory, Microsoft Active Directory (through AWS Managed Microsoft AD or AD Connector), or an external identity provider (IdP) using SAML.
• Provisioning. With an external IdP, SCIM (System for Cross domain Identity Management) automatically syncs users and groups.
• Permission sets. Templates of policies. When assigned, Identity Center creates a role in each target account and users assume it for a session.
• Access. Users sign in to an access portal, then get short lived credentials for the console or the CLI.
• Management. Enable it at the organization level and delegate administration to a member account, so the management account is not used for daily work.

# AWS CLI v2: sign in with an Identity Center profile and use it
aws configure sso
aws sso login --profile dev-account
aws s3 ls --profile dev-account

Identity Center supports attributes for access control, which pass user attributes as session tags so that policies can use attribute based access control (ABAC). It also supports requiring multi factor authentication (MFA) for sign in.

IAM federation with an identity provider

You can federate directly with an IAM identity provider instead of using Identity Center. This suits a single account or a legacy design.

The role trust policy names the provider and conditions, and the user receives temporary credentials from the AWS Security Token Service (STS). OIDC federation is also how external workloads, such as a CI/CD pipeline from an external service or a Kubernetes service account, obtain AWS roles without storing access keys.

{
  "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:*" }
    }
  }]
}

The sub condition is what limits the role to one repository. Without it, any workflow from that identity provider could assume the role.

Directory services

IAM users

IAM users have long term credentials, which are a standing risk. Use them only where a role or federation is not possible, such as some third party tools. When you must use them, enforce a strong password policy, require MFA, rotate access keys, and review them with the IAM credential report.

Choosing

Root user

The root user of each account has unrestricted access. Protect it with a strong password, MFA, no access keys, and use it only for the few tasks that require it. AWS Organizations can centrally manage root credentials for member accounts, which removes the need to keep a root password and MFA per account.