Human identities: sign-in, federation and MFA

IAM Identity Center and permission sets

IAM Identity Center (the old name was AWS SSO) is AWS's recommended way to give people access to many AWS accounts. You connect one identity source, create permission sets (templates of policies), and assign a user or group + a permission set + an account. Identity Center then creates an IAM role in that account for you. People sign in once at the AWS access portal and pick the account and role they need. No IAM users, no long-term keys.

"userIdentity": {
  "type": "AssumedRole",
  "arn": "arn:aws:sts::111122223333:assumed-role/
          AWSReservedSSO_DBAdmin_3f1a2b4c5d6e7f80/minh@example.com",
  "sessionContext": { "sessionIssuer": {
      "arn": "arn:aws:iam::111122223333:role/aws-reserved/
              sso.amazonaws.com/eu-west-1/AWSReservedSSO_DBAdmin_3f1a2b4c5d6e7f80" } }
}

Identity sources, SCIM and attributes

Identity Center needs to know who your people are. It has exactly one identity source at a time: the built-in Identity Center directory, Active Directory (AWS Managed Microsoft AD or AD Connector), or an external IdP such as Okta or Entra ID. With an external IdP, two separate standards do two separate jobs: SAML 2.0 signs people in, and SCIM copies users and groups into Identity Center so you can assign them.

Attributes for access control (ABAC in Identity Center)

Identity Center can pass user attributes, such as Department or CostCenter, into every role session as session tags. Your permission set policies then check aws:PrincipalTag/Department against resource tags. Values come from the Identity Center directory, AD attributes, SCIM-synced attributes, or a SAML attribute named https://aws.amazon.com/SAML/Attributes/AccessControl:<Key>. If both the Identity Center mapping and the SAML assertion supply a value, the Identity Center mapping wins.

{ "Effect": "Allow",
  "Action": ["ec2:StartInstances", "ec2:StopInstances"],
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": { "StringEquals": {
      "aws:ResourceTag/Team": "${aws:PrincipalTag/Team}" } } }

SAML 2.0 and OIDC federation with IAM

Before Identity Center, companies federated directly with IAM, and the exam still tests it. You create an IAM identity provider (SAML or OIDC) in the account, then roles that trust it. Your IdP signs people in and hands them a token; STS swaps it for temporary role credentials with AssumeRoleWithSAML or AssumeRoleWithWebIdentity. It's per account, so it fits one account or a special case, while Identity Center fits many accounts.

Assertion attributes AWS reads:
https://aws.amazon.com/SAML/Attributes/Role             "arn:…:role/Admin,arn:…:saml-provider/Okta"
https://aws.amazon.com/SAML/Attributes/RoleSessionName  "minh@example.com"
https://aws.amazon.com/SAML/Attributes/SessionDuration  "3600"   (900–43200 s, ≤ role max)
https://aws.amazon.com/SAML/Attributes/PrincipalTag:Dept "Finance"  (needs sts:TagSession)

{ "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::111122223333:saml-provider/Okta" },
  "Action": ["sts:AssumeRoleWithSAML", "sts:TagSession"],
  "Condition": { "StringEquals": {
      "saml:aud": "https://eu-west-1.signin.aws.amazon.com/saml" } } }

AWS Directory Service

Many companies already run Microsoft Active Directory. AWS Directory Service lets AWS workloads and services use AD. The exam loves the three choices: AWS Managed Microsoft AD (a real AD that AWS runs for you), AD Connector (a proxy back to your on-premises AD, stores nothing in AWS) and Simple AD (a small Samba-based AD-compatible directory).

aws ssm create-association --name AWS-JoinDirectoryServiceDomain \
  --targets Key=tag:DomainJoin,Values=yes \
  --parameters directoryId=d-1234567890,directoryName=corp.example.com,\
dnsIpAddresses=10.0.1.10,10.0.2.10

Multi-factor authentication (MFA)

MFA adds “something you have” to “something you know”. In AWS it appears in three places: IAM users and the root user (devices registered in IAM), IAM Identity Center (its own MFA settings for its directory or AD), and external IdPs (MFA happens at Okta or Entra ID before AWS ever sees the user). Policies can then require MFA with condition keys.

{ "Sid": "DenyAllExceptListedIfNoMFA",
  "Effect": "Deny",
  "NotAction": [ "iam:CreateVirtualMFADevice", "iam:EnableMFADevice",
                 "iam:GetUser", "iam:ListMFADevices", "iam:ListVirtualMFADevices",
                 "iam:ResyncMFADevice", "sts:GetSessionToken" ],
  "Resource": "*",
  "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } } }

Amazon Cognito: user pools and identity pools

Identity Center is for your staff. Amazon Cognito is for the customers of your web and mobile apps. It has two parts that the exam loves to swap: a user pool is a user directory that signs people in and issues JWT tokens; an identity pool exchanges a token for temporary AWS credentials so the app can call AWS services such as S3 or DynamoDB directly.

Threat protection (previously called advanced security features) in user pools can detect compromised credentials and score sign-in risk (adaptive authentication), then allow, require MFA or block. Lambda triggers let you customize sign-up and sign-in, for example a pre-token-generation trigger that adds claims.

// Trust policy
{ "Effect": "Allow",
  "Principal": { "Federated": "cognito-identity.amazonaws.com" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": { "cognito-identity.amazonaws.com:aud": "eu-west-1:1a2b3c4d-…" },
    "ForAnyValue:StringLike": { "cognito-identity.amazonaws.com:amr": "authenticated" } } }

// Permissions policy
{ "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::photos-app/users/${cognito-identity.amazonaws.com:sub}/*" }

Troubleshooting authentication

Skill 4.1.3 asks you to troubleshoot sign-in problems with CloudTrail, Cognito, permission sets and Directory Service. The trick is to find which step failed: did the person fail to sign in, fail to get credentials for a role, or get credentials but then hit AccessDenied? Each step leaves different evidence.

{ "eventSource": "sts.amazonaws.com",
  "eventName": "AssumeRoleWithSAML",
  "errorCode": "AccessDenied",
  "errorMessage": "Not authorized to perform sts:AssumeRoleWithSAML",
  "requestParameters": {
     "roleArn": "arn:aws:iam::111122223333:role/Finance",
     "principalArn": "arn:aws:iam::111122223333:saml-provider/Okta" } }

Cheatsheet extras: AD FS trusts, AD trust directions and Cognito sign-up checks

You learned SAML federation in section 3. Your cheat sheet adds the AD FS vocabulary that older questions use (“trusted identity provider”, “relying party”, “two-way trust”) and two related traps: Active Directory trust directions and Cognito sign-up checks.

AD trust directions in one picture

A trust has a trusting domain (it owns the resources) and a trusted domain (it owns the users). Access flows the opposite way to the trust. In the AWS Directory Service console you create the trust on your AWS Managed Microsoft AD:

Cognito: checking a sign-up before it happens

A Cognito user pool can call Lambda functions at fixed points. The Pre sign-up trigger runs before a user is created and can reject the registration (for example by country, e-mail domain or a fraud score). Other useful triggers: Pre authentication (block a sign-in), Post authentication, Pre token generation (add or remove claims), Define/Create/Verify auth challenge (custom MFA), User migration and Custom message. AWS WAF can also be associated with a user pool, but it filters all requests by IP or geography; it isn’t a validation step inside registration.

// Trust policy on role ADFS-Dev
{ "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::111122223333:saml-provider/ADFS" },
  "Action": "sts:AssumeRoleWithSAML",
  "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } }

// Value of claim https://aws.amazon.com/SAML/Attributes/Role for a user in AD group AWS-111122223333-Dev
arn:aws:iam::111122223333:saml-provider/ADFS,arn:aws:iam::111122223333:role/ADFS-Dev

Latest AWS update · IAM Identity Center in more than one Region (2026)

Identity Center used to live in a single Region: if that Region had a problem, nobody could sign in to their accounts through it. In February 2026 AWS added multi-Region replication for organization instances that use an external IdP, and in July 2026 extended it to the Identity Center directory. You pick extra Regions; users, groups and assignments are copied there automatically. Administration stays in the primary Region, but users can still reach their AWS accounts through a replica Region if the primary one is disrupted.

Lecture summary map

Day 4 on one screen: the mind map, the “front doors” picture, and the keyword chart.

1. Mind map

2. Which front door does each person use?

3. “If the question says… pick…”

Must-remember cheat sheet

Core quiz

Check the basics first. Pick an answer, then press Check.

Hard quiz

Harder than most real exam questions on purpose. One is an ordering question, like the new SCS-C03 format. Aim for 9 out of 12 before Day 5.

Practice test questions (from your mock exams)

These questions come from your own mock exams (the SCS-003 mock 1–9 files in your study folder), matched to this lecture. Wording was tidied and checked against current AWS behavior; where a mock answer was outdated or wrong, the explanation says so. The source is shown at the end of each explanation, like “(Mock 5 · Q12)”. Pick an answer, then press Check. Questions marked (New) were written in October 2026 for exam-guide skills or AWS changes that the mocks don’t cover.

Hands-on lab (30 minutes)

1. In a sandbox organization, enable IAM Identity Center (organization instance) and keep the Identity Center directory as source. Create a user and group lab-readers.
2. Create permission set LabReadOnly with ReadOnlyAccess and a 2-hour session, and assign the group to one account.
3. Open IAM in that account and find the AWSReservedSSO_LabReadOnly_… role. Try to edit it and read the message.
4. Run aws configure sso, then aws sso login and aws sts get-caller-identity. Note the role session name.
5. In CloudTrail Event history, filter by event source signin.amazonaws.com and find your sign-in.
6. Bonus: create a Cognito user pool and identity pool, sign in with the hosted login page and call GetCredentialsForIdentity.