What's changed: Deepened SCS-C02 Chapter 4 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
4.2Federation and Cross-Account Access
Understand temporary credentials and federation—IAM roles (AssumeRole), SAML/OIDC federation, IAM Identity Center, ExternalId, and STS. Delegate securely without long-lived keys.
Secure access uses temporary credentials. Avoid long-lived keys; use role assumption and federation.
4.2.1Temporary credentials and federation
- AssumeRole/STS: assume a role for temporary credentials (no long-lived keys).
- SAML/OIDC federation: access AWS with existing corporate IdP identities.
- IAM Identity Center: centralize SSO and permission sets across accounts.
- Trust policy/ExternalId: define who can assume; use ExternalId for third parties to prevent the confused-deputy problem.
Common on SCS-C02: temporary credentials = AssumeRole/STS (no long-lived keys), corporate IdP = SAML/OIDC federation, multi-account SSO = IAM Identity Center, third parties = ExternalId to prevent confused deputy. A cross-account role needs both a trust policy (who) and a permissions policy (what).
SCS-C02 federation design probes "eliminating long-lived keys and delegating securely with temporary credentials." STS-issued temporary credentials are short-lived, limiting damage on leak. A cross-account role sets, on the assumed side, both a trust policy (who can AssumeRole = Principal) and a permissions policy (what they can do), while the assuming side needs sts:AssumeRole permission. Corporate identity uses SAML federation (AD FS, etc. via SAML 2.0) and OIDC federation (AssumeRoleWithWebIdentity) for web/mobile or GitHub Actions, mapping IdP identities to IAM roles. For multi-account human access, IAM Identity Center is the go-to, integrating external IdPs (Entra ID/Okta) and centralizing cross-account access via permission sets (no per-account IAM users). When granting a role to a third party (SaaS vendor), add an ExternalId condition to the trust policy to prevent the confused-deputy problem—where an attacker impersonates another customer to access via the vendor. As a rule, issue no long-lived IAM users/access keys to people or services, using role assumption or federation for temporary credentials. The key is to correctly use STS temporary credentials + the two-part trust/permissions policy, SAML/OIDC for corporate ID, Identity Center for human SSO, and ExternalId for third parties.
| Scenario | Means | Key point |
|---|---|---|
| Cross-account access | AssumeRole (trust + permissions) | Temporary creds; no long-lived keys |
| Corporate ID into AWS | SAML / OIDC federation | Map IdP identity to a role |
| Human SSO across accounts | IAM Identity Center | Permission sets; external IdP |
| Delegate to third party | ExternalId condition | Prevent confused deputy |
Scenario: Let a monitoring SaaS vendor assume a read-only role in your account, while preventing impersonation. → Create a cross-account role for the vendor, with a trust policy naming the vendor’s account as Principal and requiring an ExternalId condition (a unique ID the vendor issues per customer). This stops a third party impersonating another customer from assuming the role, preventing the confused-deputy problem. Minimize the permissions policy to read-only, operating on STS temporary credentials.
FAQ: SAML federation vs IAM Identity Center? SAML federation is the traditional approach of registering an IdP in IAM and mapping to roles, configured individually. IAM Identity Center is a managed way to centralize SSO and permission sets across accounts/apps, with easy external-IdP integration. For new multi-account environments, Identity Center is recommended. Both eliminate long-lived keys in favor of temporary credentials.
Exam trap: For cross-account access, "storing the other account’s long-lived access keys in your account" is wrong—high leak risk and an anti-pattern. The answer is to assume a role via AssumeRole (temporary credentials). Also, granting a role to an external SaaS without an ExternalId risks the confused-deputy problem, letting an attacker impersonating another customer gain access.
4.2.2Section summary
- Temporary creds = AssumeRole/STS / corporate ID = SAML/OIDC
- SSO = IAM Identity Center / third parties = ExternalId
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. An app in account A accesses account B’s resources securely without long-lived keys. What?
Q2. Granting a cross-account role to a third party, prevent the confused-deputy problem. What condition?
Q3. Let employees SSO into multiple AWS accounts with existing corporate identities. What?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.