Workforce identity and federation

Exam tasks: 4.1 (Skills 4.1.1 identity solutions and IdP integration with Identity Center and MFA, 4.1.3 troubleshooting Identity Center permission sets and Directory Service), 4.2 (Skill 4.2.2 ABAC from attributes)

The decision: where do your employees' identities already live, and how do you turn them into short-lived access to many AWS accounts without creating IAM users?

Picking the setupCopy Anchor Link

IAM Identity CenterCopy Anchor Link

• One identity source per organization: the Identity Center directory, Active Directory, or an external IdP. Changing the source can remove existing assignments, so plan it.
• Permission sets are templates of policies (AWS managed, customer managed by name, inline, and an optional permissions boundary). Assigning a permission set to a user or group for an account creates a role named AWSReservedSSO_<set>_<id> in that account.
• Session duration is set on the permission set, from 1 to 12 hours. Default is 1 hour.
• Customer managed policies referenced by a permission set must exist by name in every target account, or the provisioning fails.
• Delegate administration to a member account so daily work doesn't happen in the management account.
• The same sign-in also covers the CLI (aws configure sso) and applications through trusted identity propagation, which carries the user's identity to services such as Redshift or S3 Access Grants.

External IdP: SAML plus SCIMCopy Anchor Link

• SAML 2.0 handles sign-in: the IdP authenticates the user and sends an assertion to Identity Center.
• SCIM handles provisioning: users and groups are created and removed in Identity Center automatically. Without SCIM, you create users by hand, and SAML sign-in fails for any user who doesn't exist in Identity Center.
• MFA is enforced by the external IdP. Identity Center's own MFA settings don't apply to external IdP users.

Active Directory optionsCopy Anchor Link

• Simple AD isn't supported as an Identity Center source.
• Troubleshooting a failed AD sign-in: check VPN or Direct Connect reachability to the DCs, security groups for DNS, Kerberos and LDAP ports, the AD Connector service account's permissions, and the trust direction.

Direct SAML federation to IAMCopy Anchor Link

• Create a SAML identity provider in IAM with the IdP's metadata, and roles whose trust policy allows sts:AssumeRoleWithSAML from that provider, checking SAML:aud.
• The assertion's Role attribute lists the role and provider ARNs the user may assume. RoleSessionName and SessionDuration attributes set the session name and length.
• It works per account, so each account needs its own provider and roles. That's why Identity Center is the default answer for organizations.
• OIDC providers (for example a CI system issuing JWTs) work the same way through AssumeRoleWithWebIdentity.

ABAC from IdP attributesCopy Anchor Link

Attributes such as department or cost centre travel from the IdP into the session as principal tags, and policies compare them with resource tags. One policy then covers every team.

• In Identity Center, turn on attributes for access control and map each key to an identity-store attribute or to the SAML attribute https://aws.amazon.com/SAML/Attributes/AccessControl:<key>.
• With direct IAM federation, send https://aws.amazon.com/SAML/Attributes/PrincipalTag:<key> in the assertion. The role's trust policy must also allow sts:TagSession.
• Deny users changing the tags that the policy relies on, or they can tag themselves into access.

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

MFA for peopleCopy Anchor Link

• Identity Center (its own directory or AD): prompt every sign-in or only when the sign-in context changes, allow FIDO2 authenticators (passkeys, security keys) and authenticator apps, and choose what happens for users without a device (require registration at sign-in, block, or email one-time code).
• IAM users and root: up to 8 MFA devices each, including passkeys, security keys, virtual TOTP apps and hardware TOTP tokens. SMS isn't supported. Root MFA is enforced by default.
• API calls: MFA only counts if it was part of the session, through GetSessionToken or AssumeRole with SerialNumber and TokenCode. See temporary credentials.

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• What is IAM Identity Center?
• Attributes for access control in IAM Identity Center
• SAML 2.0 federation
• AWS Directory Service: which directory to choose