Federation, Application Auth and Workload Identity

What it is

Every request to AWS comes from an identity, and the professional exam asks you to pick the right identity system for three different callers. Employees need single sign on to many accounts, customers need to sign in to your application, and workloads need credentials without stored secrets.

The common thread is federation: trust an identity that already exists somewhere else and exchange it for short-lived AWS credentials. Long-term access keys are almost never the answer.

How it works

Workforce federation with IAM Identity Center

IAM Identity Center is the recommended way to give people access to many accounts in an organization. You connect one identity source: its own directory, Active Directory, or an external identity provider (IdP) such as Okta or Microsoft Entra ID.

Two standard protocols do different jobs. SAML 2.0 handles authentication, so the user signs in at the IdP and Identity Center trusts the assertion. SCIM (System for Cross-domain Identity Management) handles provisioning, so users and groups created or removed in the IdP appear or disappear in Identity Center automatically.

Access is granted by assigning a group a permission set in an account. Identity Center creates a matching role in each assigned account, so a change to the permission set reaches every account at once.

Direct IAM federation

IAM can also trust an IdP directly. An IAM SAML provider plus AssumeRoleWithSAML suits a single account or a legacy setup. An IAM OpenID Connect (OIDC) provider plus AssumeRoleWithWebIdentity suits workloads that hold an OIDC token, such as a CI/CD system that deploys into AWS without stored keys.

Application users with Amazon Cognito

A user pool is a user directory and OAuth 2.0 / OIDC provider for your app. It handles sign up, sign in, MFA and federation with social or enterprise IdPs, and it issues JSON Web Tokens (ID, access and refresh tokens).

An identity pool exchanges a token (from a user pool or another IdP) for temporary AWS credentials. Use it when the client itself must call AWS services, such as uploading to an S3 prefix for that user.

OAuth 2.0 grants matter here. The authorization code grant (with PKCE for public clients) suits interactive users. The client credentials grant suits machine to machine calls, where a user pool app client gets an access token with custom scopes from a resource server.

For fine-grained permissions inside the app, Amazon Verified Permissions evaluates Cedar policies against the token claims.

Workload identity on Amazon EKS

EKS Pod Identity gives a Kubernetes service account an IAM role. You install the EKS Pod Identity Agent add-on and create a pod identity association (cluster, namespace, service account, role). The role trusts the service principal pods.eks.amazonaws.com, so the same role can be reused across clusters without an OIDC provider per cluster.

IAM Roles for Service Accounts (IRSA) is the older option and still works. It needs an OIDC provider for each cluster and a trust policy that names that provider.

Workloads outside AWS with IAM Roles Anywhere

Servers, containers and applications that run on premises or in another cloud can get temporary credentials through IAM Roles Anywhere. The workload holds an X.509 certificate issued by your certificate authority (CA).

You register the CA as a trust anchor, either AWS Private CA or an external CA certificate. A profile lists which roles can be assumed and can add a session policy, and each role trusts the IAM Roles Anywhere service principal.

The trust boundary is the account: any certificate from a trust anchor in the account can assume any role that trusts the service, unless the role trust policy adds conditions such as the trust anchor ARN or certificate attributes.

How the exam asks about this

• "Employees use an existing IdP, and access to 80 accounts must be removed automatically when someone leaves." -> IAM Identity Center with SAML 2.0 for sign in and SCIM for provisioning.
• "A mobile app must let each signed-in user upload only to their own S3 prefix." -> Cognito user pool for sign in, identity pool for credentials, with a role policy scoped by the identity ID.
• "On-premises servers use long-term access keys to reach S3, and the company already runs a private CA." -> IAM Roles Anywhere with the CA as a trust anchor.