IAM Identity Center and federation
Lesson 1 of 4 in Authentication Strategies.
Domain 4 is the heaviest on the exam — 20% of scored content, up from 16% in SCS-C02 — and it opens with the question every multi-account estate has to answer: how do humans sign in?
There is a wrong answer that still appears in real environments and in exam distractors: an IAM user per person per account. It fails on every axis the exam cares about. Credentials are long-lived, so a leaked access key works until someone notices. Offboarding means hunting through accounts. There is no single place to see who has access to what. And nothing ties the AWS identity to the corporate directory that already knows whether the person still works here.
AWS IAM Identity Center is the answer, and the reflex worth drilling: "manage human access at scale across many AWS accounts" → Identity Center, not IAM users. One sign-in portal, identities mastered wherever they already live, and every session temporary by construction. Watch one sign-in happen.
Three mechanics from that board get tested directly.
Permission sets materialise as IAM roles. A permission set is a bundle — AWS managed policies, an inline policy, optionally a customer managed policy name, a permissions boundary, and a session duration — authored once in the Identity Center delegated administrator or management account. Assigning it to an account provisions a role there named AWSReservedSSO_<permission-set-name>_<unique-suffix>, under the path /aws-reserved/sso.amazonaws.com/. The role is protected: IAM will refuse to let you edit it. Two consequences worth remembering. First, anything that needs to name the principal — a bucket policy, a KMS key policy, an EKS access entry — should match the path with a wildcard rather than the exact ARN, because deleting the last assignment deletes the role and a later re-assignment creates one with a different suffix. Second, editing a permission set does not push itself out; the assignment must be re-provisioned, which is the ordinary explanation for "the policy is right but the user still cannot do it".
The identity source is a one-way door in practice. Changing it resets assignments, so it is an early decision.
| Identity source | Who owns the user lifecycle | How users arrive | Choose it when |
|---|---|---|---|
Identity Center directory | Identity Center itself | Created by hand, or by SCIM from a supported IdP | There is no corporate directory to integrate — a small team, a greenfield organization, or a lab |
Active Directory | Your AD forest | AWS Managed Microsoft AD, or AD Connector proxying to on-premises AD | A Windows estate already owns identity and you want AWS sign-in to use the same accounts, groups, and password policy |
External identity provider | Entra ID, Okta, Ping, or similar | SAML 2.0 for sign-in plus SCIM for provisioning | The scenario says identities live in a cloud IdP, or that MFA and conditional access are enforced centrally there — the most common answer today |
Federation can also go straight to IAM, without Identity Center, and the exam expects the mechanics of both protocols.
With SAML 2.0 you upload the IdP's metadata document to create an IAM SAML identity provider object, then write a role trust policy that trusts it — conventionally with StringEquals on SAML:aud equal to https://signin.aws.amazon.com/saml so an assertion minted for a different relying party cannot be replayed at AWS. The IdP sends an assertion whose Role attribute carries role-ARN,provider-ARN pairs; the client calls AssumeRoleWithSAML, which needs no AWS credentials at all, and receives a session of up to 12 hours. The assertion can also supply RoleSessionName (what appears in CloudTrail), PrincipalTag:<key> session tags, and TransitiveTagKeys.
With OIDC you register an IAM OIDC identity provider for the issuer and audience, and the caller exchanges a signed identity token through AssumeRoleWithWebIdentity. This is the modern pattern for machine identity outside AWS: a CI pipeline, a mobile app, a Kubernetes service account. The security lives in the trust-policy conditions on the token claims — pin the aud claim, and pin sub to the exact repository, branch, or service account. A trust policy that names the OIDC provider but leaves sub unconstrained trusts every workload that provider can mint a token for, which for a public CI service means everyone's.
Attribute-based access from identity-source attributes
Identity Center can enable attributes for access control, projecting attributes from the identity source — AD attributes, SAML assertion claims, or attributes you configure — into the session as aws:PrincipalTag/<key>. One permission set then serves every team: "Condition": {"StringEquals": {"aws:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}"}}. This is ABAC for workforce access, and it is also the supported way to carry the IdP’s authentication method into AWS so a policy can insist the person used MFA — [aws:MultiFactorAuthPresent](/certifications/glossary?term=mfa-condition-key) is not populated for federated identities.
Delegated administration
Identity Center is enabled from the organization management account, but day-to-day administration can be delegated to a member account (commonly a dedicated identity or security-tooling account) so that routine assignment work does not require management-account credentials. A short list of operations stays in the management account, including managing permission sets that grant access to the management account.
Session duration, and what ends a session
A permission set carries its own session duration (up to 12 hours), and the portal session has its own lifetime. Revoking access has two halves worth separating on the exam: deleting the assignment stops new sessions immediately, while an already-issued credential remains valid until it expires unless you also revoke it — delete the assignment and, if it matters, attach a time-based deny to the role (see Finding and fixing over-permission).
Trusted identity propagation
For AWS services that make decisions about the person rather than the role — Amazon Q Business, Amazon Redshift query access, S3 Access Grants — Identity Center can propagate the user identity through the request so service-side authorization and the audit trail name the human, not a shared role. Recognise it when a stem wants per-user authorization and per-user audit inside a managed analytics or assistant service.
Amazon Q Business is the in-scope example worth knowing concretely, because it is where propagated identity becomes an access-control boundary. Its data-source connectors crawl the document ACLs from the source system, and retrieval is filtered to documents whose ACL contains the asking user — so the assistant cannot summarise a file the user could not open themselves. Two failure modes follow, and both look like bugs rather than security:
- An identity mismatch reads as "no results". The filter matches the user as they exist in the Identity Center user store. If a connector ingested an ACL naming a different alias or address for the same human, Q Business answers "I could not find relevant information" — an authorization outcome wearing the costume of a retrieval failure. The fix is aligning the alias in the user store, not re-indexing.
- ACL crawling is not a switch you can flip. Turning it off or on is a property of the data source; changing it means deleting and recreating that data source. An application stood up with ACLs disabled "for the pilot" cannot be quietly tightened later without a re-ingest.
Key terms: AWS IAM Identity Center, Permission set, Identity source (IAM Identity Center), SCIM provisioning, SAML 2.0 federation, OIDC / web identity federation
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.