SAP-C03 Identity Security Architecture: Identity Center Federation, Cognito, EKS Pod Identity, Least Privilege, ABAC and Data Perimeters

IAM Identity Center federates a workforce by trusting an external identity provider (IdP) such as Okta, Microsoft Entra ID or Ping for sign-in through SAML 2.0, and by receiving the IdP's users and groups through SCIM provisioning. Users sign in once at the IdP and see every account and permission set they are assigned. Identity Center is enabled once per organization (in the management account, or as an account instance for a single account), and it replaces per-account IAM users and per-account IAM SAML providers for human access.

The two protocols do different jobs, and an external-IdP design needs both:

Identity Center does not create users just in time from a SAML assertion: a user must already exist in the identity store, matched by user name, before sign-in succeeds. Turning on automatic provisioning gives you an SCIM endpoint and an access token that you configure in the IdP. With SCIM in place, disabling or removing someone in the IdP removes their AWS access with no AWS-side work, which is the usual joiner-mover-leaver requirement. (You can instead keep users in the Identity Center identity store or connect AWS Managed Microsoft AD or a self-managed AD through AD Connector; only one identity source is active at a time.)

Compare the older pattern: an IAM SAML identity provider created in each account, with IdP groups mapped to IAM roles per account. It works, but every account needs its own provider, roles and mappings, and there is no central assignment view. An IAM SAML provider remains the right tool for a single account or for an application that needs it, but for many accounts in AWS Organizations, Identity Center is the managed answer. Amazon Cognito is for your application's customers, not for workforce access to AWS accounts.

A permission set defines what access looks like; an assignment gives a user or group that permission set in a chosen account. When you assign it, Identity Center provisions an IAM role (named AWSReservedSSO_<name>_…, under the /aws-reserved/sso.amazonaws.com/ path) in each target account, and it updates every copy when you change and reprovision the permission set. This gives one definition, maintained in one place, that applies to many accounts and cannot drift account by account.

A permission set can contain:

• AWS managed policies and one inline policy, copied into every provisioned role.
• Customer managed policy references: a name and path only. Each assigned account must already contain a customer managed policy with that exact name and path, and Identity Center attaches that account's own copy. This lets one permission set name account-specific resources (each account's buckets, for example). If the policy is missing in an account, provisioning to that account fails; deploy the policies first, for example with CloudFormation StackSets.
• A permissions boundary, given as an AWS managed policy or a customer managed policy reference (same rule: the policy must exist in each account).
• A session duration and an optional relay state (the console page users land on).

Administering Identity Center outside the management account

The Identity Center organization instance lives in the management account and cannot be moved. To keep daily administrators out of the management account, register a member account (often a security tooling account) as the delegated administrator; most administration then happens there. AWS keeps one protection in place: a permission set provisioned to the management account can be changed only from the management account, so management-account access stays under management-account control. Best practice is to use dedicated permission sets for the management account and to assign them to individual users rather than IdP groups, because anyone who controls group membership in the IdP could otherwise grant themselves management-account access.

Attributes for access control

Identity Center can pass user attributes into every session as session tags (principal tags), so one permission set supports attribute-based access control (ABAC) across accounts. Enable attributes for access control, then either send the attribute from the external IdP in the SAML assertion (attribute name https://aws.amazon.com/SAML/Attributes/AccessControl:<key>) or, when users live in the identity store or come through SCIM, map a key to an identity store attribute with path syntax such as ${path:enterprise.department}. Policies in the permission set then compare aws:PrincipalTag/<key> with resource tags. Tagging the shared provisioned role itself does not help: every user of that role would carry the same tag. Identity store users cannot carry IAM tags.

Use an Amazon Cognito user pool when your application needs to know who the user is: it is a managed user directory and OpenID Connect / OAuth 2.0 authorization server that handles sign-up, sign-in, MFA and federation, and issues JSON Web Tokens. Use an Amazon Cognito identity pool when the app must call AWS services directly and needs temporary AWS credentials. Many apps use both: the user pool authenticates, and the identity pool exchanges the user pool token for credentials.

Federation through a user pool

A user pool can add many SAML 2.0 and OIDC identity providers and still issue tokens from one issuer, so the application validates a single token format. For a B2B SaaS with many enterprise customers, add each customer's IdP as a SAML provider in one user pool, enable it on the app client, and set the provider's identifiers to the customer's email domains so managed login routes each user to the right IdP from their email address, with no company picker and no pool per customer.

Load balancer authentication

An Application Load Balancer can authenticate users before forwarding requests: put an authenticate-cognito or authenticate-oidc action before the forward action in an HTTPS listener rule, and unauthenticated requests never reach the targets. The ALB speaks only OIDC (directly or through Cognito); it cannot talk SAML. For a SAML-only corporate IdP, put a user pool in between (SAML provider in the pool, an app client for the ALB, then authenticate-cognito).

OAuth 2.0 for machine-to-machine APIs

When no human is involved, use the client credentials grant: define a resource server in the user pool with custom scopes (for example invoices/read and invoices/write), create one app client with a client secret per partner, and allow each client only the scopes it should have. Each client is revocable on its own. On API Gateway, a Cognito authorizer plus OAuth scopes on each method enforces this with no custom code. API keys and usage plans are for throttling and quotas, not authorization.

Know which token goes where. The ID token describes the user (for the app); the access token carries the granted scopes (for APIs). If a method has OAuth scopes configured, the Cognito authorizer accepts only an access token that contains a required scope; without scopes, it accepts the ID token. Adding scopes to a method and still sending ID tokens yields 401 Unauthorized.

Scoped AWS credentials from an identity pool

An identity pool turns an identity token (from a user pool, a social provider, SAML or OIDC) into temporary AWS credentials for an IAM role, so a mobile or web app can call S3, DynamoDB or other services directly without long-term keys and without a backend that signs requests. Each user gets a stable identity ID.

• Guest access: enabling unauthenticated identities gives visitors who have not signed in credentials for a separate, narrowly scoped guest role (read-only browsing, for example), while signed-in users get the authenticated role.
• Per-user scoping: the policy variable ${cognito-identity.amazonaws.com:sub} is the caller's identity ID, so a resource ARN such as arn:aws:s3:::bucket/${cognito-identity.amazonaws.com:sub}/* lets each user reach only their own prefix with one role.
• Role selection: use the default authenticated role, choose the role from the token (user pool groups carry IAM roles, which appear as cognito:roles and cognito:preferred_role claims), or choose the role with rules that match claim values. Rules work but grow with every value you add.
• Attributes for access control: map token claims (for example a custom department attribute) to principal tags on the session, then use ${aws:PrincipalTag/department} in policies. Combined with token-based role selection, groups decide which actions and tags decide which data, with no role, rule or group per attribute value.

A user pool token sent straight to S3 or DynamoDB is not an AWS credential and is rejected; S3 access points and bucket policies cannot validate Cognito tokens. Presigned URLs also work for uploads, but they need a backend service that holds credentials and signs each URL; an identity pool needs no such service.

Give each Kubernetes service account its own IAM role through EKS Pod Identity or IAM roles for service accounts (IRSA); never rely on the node instance role, which every pod on the node can use, and never mount access keys into pods.

Pod Identity also separates duties: the IAM team owns roles and policies, the cluster team owns associations, and nobody has to create OIDC providers. Its session tags enable ABAC: one role whose S3 resource is bucket/${aws:PrincipalTag/kubernetes-namespace}/* isolates every namespace, including namespaces created later. For pods that must run on Fargate, use IRSA. The Fargate pod execution role is for pulling images and writing logs, not for the application's own AWS calls.

A workload outside AWS gets temporary credentials by federating the identity it already has: an OpenID Connect token goes through an IAM OIDC identity provider, and an X.509 certificate goes through IAM Roles Anywhere. Long-term IAM user access keys, even when rotated or stored in a secrets manager, are the pattern these replace.

Scoping OIDC trust

The role trust policy must check both claims. aud says the token was issued for AWS (for GitHub, sts.amazonaws.com); sub says which workload is asking. For GitHub Actions, sub looks like repo:<org>/<repo>:ref:refs/heads/<branch> (or …:environment:<name> when environments are used). A trust policy that checks only aud lets any repository on the platform assume the role; a wildcard across the organization's repositories is broader than "only this repo's main branch". Use StringEquals on the exact sub when one workload should qualify.

IAM Roles Anywhere

Register the CA as a trust anchor (AWS Private CA or an external CA's certificate bundle), create a profile that lists the roles that can be assumed (with optional session policies and duration), and give the role a trust policy for rolesanywhere.amazonaws.com allowing sts:AssumeRole, sts:TagSession and sts:SetSourceIdentity, ideally limited with aws:SourceArn to the trust anchor. Certificate fields become session principal tags, so a trust policy can require, for example, aws:PrincipalTag/x509Subject/OU to equal a specific organizational unit. The certificate's common name becomes the source identity. For revocation, Roles Anywhere checks only CRLs that you import into it (and update by re-importing); it never calls CRL distribution points or OCSP responders. Shortening sessions does not stop a stolen, valid certificate from creating new sessions.

Outbound identity federation

The reverse direction: an AWS workload calling a third-party API that accepts bearer JWTs. With outbound identity federation enabled in an account, a role calls sts:GetWebIdentityToken for a chosen audience and receives a short-lived JWT signed by the account's issuer, which the external service verifies against the issuer's published keys. IAM policies control which roles may request tokens and for which audiences, and no shared client secret exists anywhere. An IAM OIDC provider for the partner would be inbound federation, the opposite direction.

Cross-account access uses an IAM role in the target account whose trust policy names who may assume it, plus an identity policy in the caller's account that allows sts:AssumeRole on it. Both sides must allow the call. The caller receives temporary credentials; no keys are shared.

Same-account versus cross-account evaluation

Within one account, an allow in either the principal's identity-based policies or the resource's resource-based policy is enough (when nothing denies it): a role whose identity policy allows sqs:SendMessage can send to a queue in its own account even though the queue has no queue policy. Across accounts, both sides must allow: the caller's identity policy and the resource policy (or role trust policy) in the other account. So a missing resource policy explains a cross-account denial, never a same-account one; for a same-account denial, look for an explicit deny or a limit such as a permissions boundary, session policy or SCP.

External IDs and the confused deputy

When a third party (a SaaS vendor) assumes roles in many customers' accounts, a malicious customer could give the vendor another customer's role ARN and have the vendor fetch that customer's data: the confused deputy problem. The defence is an external ID that the vendor generates, unique per customer, shows to the customer as a value they cannot edit, and always sends with AssumeRole; each customer's trust policy requires sts:ExternalId to equal it. An external ID chosen by the customer fails, because a second customer could type the same value. An external ID is not a secret; its value lies in being assigned by the vendor and unique.

Trusting a role that might be recreated

When a trust policy names a role ARN as principal, IAM stores that role's unique principal ID. If the role is deleted and recreated with the same name, the ID changes, the trust policy shows an AROA… ID and assumption fails. To survive rebuilds while still trusting only that role, set the principal to the vendor's account and add a condition on aws:PrincipalArn for the role's ARN (plus the external ID). aws:SourceArn describes a resource on whose behalf a service acts, so it is not the key for role-to-role trust.

Session duration and role chaining

A role's maximum session duration can be set from 1 to 12 hours, and callers request up to that with DurationSeconds. Role chaining (using one role's session to assume another role) is capped at one hour: a chained AssumeRole that requests more than 3,600 seconds fails rather than being shortened, whatever either role's maximum is. Long jobs that chain roles must request an hour or less and refresh credentials through the first role before they expire.

Both are limits, never grants: the effective permissions are the intersection of the identity-based policies and the boundary or session policy. Anything the limit does not allow is denied, even if an attached policy such as AdministratorAccess allows it; anything the identity policies do not allow is denied, even if the limit allows it.

Delegating role creation without privilege escalation

To let developers create roles for their own functions without opening an escalation path, combine these controls in the developers' policy:

1. Allow iam:CreateRole, iam:PutRolePolicy, iam:AttachRolePolicy (and similar) only when the condition key iam:PermissionsBoundary equals the boundary's ARN.
2. Deny iam:DeleteRolePermissionsBoundary, and deny iam:CreatePolicyVersion, iam:SetDefaultPolicyVersion and iam:DeletePolicy on the boundary policy itself, so nobody can remove or rewrite the cap.
3. Require a path (for example /dev/) on created roles and allow iam:PassRole only on roles under that path, optionally with iam:PassedToService. iam:PermissionsBoundary does not apply to iam:PassRole, so without this a developer can pass an existing privileged role to a new function and act through it.

Putting the boundary on the developers' own role limits the developers, not the roles they create. An SCP that blocks role creation also blocks developer self-service: it prevents escalation by removing the delegation altogether (SCP design is covered in the multi-account governance lesson).

Session policies for multi-tenant brokers

A token broker that assumes one broad role can pass a session policy limited to one tenant's prefix on each call, so the credentials handed to a worker allow only that tenant's data. This scales to thousands of tenants because no per-tenant role or policy exists. A permissions boundary is a poor fit here: it belongs to the role, so changing it per call would affect every session at once.

ABAC grants access when an attribute of the principal matches an attribute of the resource, usually by comparing aws:PrincipalTag/<key> with aws:ResourceTag/<key>. One policy then serves any number of teams or projects; a new project needs only correctly tagged people and resources, never a new policy, role or group.

Principal tags come from tags on the IAM role or user, or from session tags passed at sign-in: SAML attributes (https://aws.amazon.com/SAML/Attributes/PrincipalTag:<key>), IAM Identity Center attributes for access control, OIDC claims, Cognito identity pool principal tags, EKS Pod Identity tags or Roles Anywhere certificate fields. Session tags override role tags with the same key, and passing them requires sts:TagSession in the trust policy.

Choosing the right condition key

Protecting the tags

ABAC is only as strong as control over tagging. If someone can change a resource's tag to their own value, they grant themselves access. Allow tagging the authorization key only when the new value (aws:RequestTag) equals the caller's principal tag and the resource already carries it, deny CreateTags/DeleteTags (or TagResource/UntagResource) on that key when the resource belongs to someone else, and make sure principals cannot choose their own session tags (they should come from the IdP).

Tags across a role chain

Session tags do not follow a session into a chained role unless they are transitive. When engineers federate into a hub role and then assume roles in workload accounts, have the IdP send the https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys attribute naming the keys to carry forward; the value then reaches every chained session and cannot be overridden later in the chain. Tagging the workload roles themselves would give every user the same value.

A data perimeter is a set of preventive guardrails that ensures only trusted identities access trusted resources from expected networks. It is built from resource-based policies, VPC endpoint policies and organization policies, each using global condition keys; IAM Access Analyzer then checks continuously that nothing is shared beyond it.

Each perimeter can be enforced in more than one place; the table names the controls that each one most often relies on, and a mature perimeter layers several.

VPC endpoint policies apply to every request through the endpoint whatever credentials are used, so an endpoint policy that allows S3 only when aws:ResourceOrgID equals your organization ID stops someone in your VPC from copying data to a personal bucket with personal keys. An SCP cannot do that: SCPs constrain only your organization's own principals. Pair it with bucket policies on sensitive buckets that deny requests not arriving through your endpoints (aws:SourceVpce). SCPs and RCPs themselves are designed in the multi-account governance lesson.

The two service exceptions

• aws:PrincipalIsAWSService is true when an AWS service principal acts on its own (AWS Config delivering configuration snapshots, VPC Flow Logs or CloudTrail delivering log files). An identity-perimeter deny on aws:PrincipalOrgID blocks those services unless the deny adds "BoolIfExists": {"aws:PrincipalIsAWSService": "false"}.
• aws:ViaAWSService is true when a service makes a request with the caller's credentials on their behalf (forward access sessions), such as Amazon S3 calling AWS KMS to decrypt an SSE-KMS object for the reader, or CloudFormation creating resources with the caller's credentials. Those calls come from AWS's network, so a network-perimeter deny on aws:SourceVpce blocks them unless it adds "BoolIfExists": {"aws:ViaAWSService": "false"}. This adds no new network path.

Validating external access with IAM Access Analyzer

For a pipeline rule such as "never allow these specific actions", CheckAccessNotGranted is the precise check; general validation warnings do not target named actions, and CheckNoNewAccess answers "did this change widen access compared with before".

AWS Verified Access provides VPN-less, zero-trust access to private applications: it evaluates every request against the user's identity and, optionally, the device's security posture, and forwards only allowed requests to the application, which stays internal. It suits employees and contractors who need specific internal web apps, not the whole network.

• Instance: the top-level resource. It has trust providers: a user identity trust provider (IAM Identity Center or an OIDC-compatible IdP) and optionally device trust providers (for example CrowdStrike, Jamf or JumpCloud). An instance takes one user identity provider and can take several device providers.
• Group: a collection of endpoints that share security requirements, with a group policy written in Cedar that tests identity and device claims (group membership, email domain, posture score).
• Endpoint: one application, typically an internal Application or Network Load Balancer or a network interface, with an optional endpoint policy.

When an endpoint has a policy, both the group policy and the endpoint policy must allow the request. So put shared requirements in the group policy and app-specific requirements (for example, membership of a Finance-Admins group for a ledger app) in that app's endpoint policy; a forbid in the group policy would hit every app in the group, and another permit adds nothing restrictive. Trust providers belong to the instance, not to individual apps.

Compared with alternatives: a client VPN grants network-level access to a VPC; an ALB with authenticate-oidc or Cognito checks identity but needs a reachable (usually internet-facing) load balancer and checks no device posture; PrivateLink connects networks, not users. Verified Access is the design that combines all three properties: no network-level access or VPN client, an identity (and optionally device) decision on every request, and an application that is never exposed to the internet.