--- cuppy_hub: aws cuppy_path: patterns/alternatives/identity-choices.md cuppy_section: docs cuppy_doc: KK2V-94ZQ cuppy_doc_uuid: 9774fe70-434b-4eb4-812f-b2d80919f4d6 cuppy_permalink: https://cuppy.io/aws/d/KK2V-94ZQ cuppy_version: 4 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/aws/docs/patterns/alternatives/identity-choices cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: badd296163716424f4bcc574f286f0fd12888ab6b5a2d799a5d484c1b50a602b # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # Identity choices **Match the mechanism to who is calling.** - **People who work for you** → IAM Identity Center, with your existing IdP as the identity source. - **Code** → IAM roles: execution, task and instance roles, or OIDC federation for CI. - **Your application's customers** → Amazon Cognito, or a third-party customer-identity service. Long-lived IAM user access keys are the fallback for none of these. ## The map | Caller | Mechanism | Works well with | Breaks or hurts when | |---|---|---|---| | Employees and contractors, many accounts | **IAM Identity Center** + external IdP (Okta, Entra ID, Google Workspace, JumpCloud, OneLogin, CyberArk, Ping) over SAML + SCIM | Organizations (organization instance); CLI `sso-session` profiles; permission sets assigned to IdP groups | Users not provisioned (no just-in-time creation); attribute mismatches; policies pinned to `AWSReservedSSO_…` ARNs that change (`reference/identity-center/provisioned-roles-and-sessions.md`) | | Employees, one or two accounts, existing IdP | IAM SAML or OIDC identity provider per account (the decision guide's per-account alternative) | Small setups | Each account configured separately; no central portal or assignments | | CI/CD (GitHub Actions and similar) | IAM OIDC identity provider + role trusting `token.actions.githubusercontent.com` with `aud` and exact `sub` conditions | Short-lived credentials per job | A `sub` wildcard (`repo:/:*`) trusts every branch (`guides/iam/ci-oidc-github.md`) | | Workloads on AWS | Lambda execution, ECS task and EC2 instance roles | SDK default credential chains | Code that calls `sts:AssumeRole` on its own role; app permissions placed on the ECS *execution* role | | End users of your web or mobile app | **Amazon Cognito** (customer identity and access management, CIAM) | Social and enterprise sign-in for apps (not collected in this hub) | Using Identity Center for customers: it is built for workforce access to AWS accounts and apps | | Fine-grained authorization inside your app | **Amazon Verified Permissions** (Cedar policies) | Externalizing app authorization | Confusing it with IAM: it decides app-level permissions, not AWS API access | | Windows workloads needing AD | AWS Directory Service (Managed Microsoft AD) | Domain join; AD as Identity Center's identity source | The AD *Domain Users* primary group doesn't sync to Identity Center | ## Identity Center with an external IdP versus the IdP's own AWS app Okta and Entra ID can federate straight into IAM roles per account (classic SAML), or act as the identity source for Identity Center. Choose Identity Center when you have several accounts. Assignments, the access portal, CLI SSO and permission sets live in one place, and the IdP only proves who the user is and which groups they belong to (`patterns/external-idp-to-identity-center.md`). The per-account SAML style puts role mapping in the IdP and is per account (detailed setup not collected). ## Things that work well together - IdP groups → SCIM → permission sets on accounts → CLI profiles per account and role. Group changes in the IdP flow through without touching AWS. - Identity Center attributes for access control (`AccessControl:` SAML attributes) → ABAC conditions on `aws:PrincipalTag`. - OIDC roles for CI plus SCPs that deny long-lived access-key creation (SCP design in `reference/organizations/scps-and-rcps.md`). ## Things that don't | Combination | Problem | |---|---| | SCIM provisioning **and** manual edits through the Identity Store API | Drift that SCIM won't correct; possible privilege escalation | | KMS key policies or EKS `aws-auth` naming exact permission-set role ARNs | Lockout when the role is recreated with a new suffix | | One IdP group used both to assign the Okta app and to push groups | Not supported | | Entra ID access granted through nested groups | Those users never reach Identity Center | | IAM users with access keys for people who also have SSO | Two identities to audit; keys outlive the person's access | | Cognito user pools as the workforce IdP for AWS console access | Not the purpose of either service; use Identity Center (UNVERIFIED that it's impossible, only that it's off-pattern per the decision guide) | --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 131 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/aws/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.