AWS Federation & SSO Architecture – Identity Center, Cognito & SAML

AWS Federation & SSO Architecture — Overview

Identity federation is the second-largest topic in SCS-C03 Domain 4 (20% of exam). Questions test IAM Identity Center (formerly AWS SSO) for workforce access, Cognito for customer-facing apps, SAML/OIDC federation patterns, and Directory Service integration. Understanding when to use which is the key exam skill.

IAM Identity Center (AWS SSO)

Feature	Details
What	Single sign-on portal for ALL AWS accounts + business applications (Salesforce, Slack, etc.)
Identity source	Built-in directory, Active Directory (Managed AD or AD Connector), or external IdP (Okta, Azure AD via SAML/SCIM)
Permission sets	Reusable permission templates assigned to users/groups per account. Creates IAM roles behind the scenes.
Multi-account	One portal → access any account in the Organization. Centrally managed.
MFA	Built-in MFA (TOTP, FIDO2/WebAuthn). Can require MFA per permission set.
ABAC	Pass attributes from IdP as session tags → use in permission sets for tag-based access control.

Amazon Cognito — User Pools vs Identity Pools

Component	Purpose	Output
User Pools	Authentication — sign-up, sign-in, MFA, password policies, account recovery	JWT tokens (ID token, Access token, Refresh token)
Identity Pools	Authorization — exchange tokens for temporary AWS credentials (STS)	AWS access key, secret key, session token (scoped IAM role)

• User Pool alone: Authenticate users → JWT → API Gateway (Cognito authorizer) → Lambda
• User Pool + Identity Pool: Authenticate → JWT → exchange for AWS credentials → direct S3/DynamoDB access from client
• Identity Pool alone: Federate external tokens (Google, Facebook, SAML) → AWS credentials without User Pool
• Unauthenticated access: Identity Pools can grant limited AWS access to anonymous users (read-only S3, etc.)

SAML 2.0 vs OIDC Federation

Protocol	Best For	AWS Integration
SAML 2.0	Enterprise SSO (Active Directory, Okta, PingFederate)	IAM Identity Center, IAM SAML Provider, Cognito User Pools
OIDC	Modern apps, social login, CI/CD (GitHub Actions)	Cognito, IAM OIDC Provider (for GitHub/GitLab CI), EKS IRSA

AWS Directory Service Options

Service	What	Use When
AWS Managed Microsoft AD	Full Microsoft AD running in AWS (2 DCs, Multi-AZ)	Need AD-aware applications (SQL Server Windows Auth, .NET apps), trust with on-prem AD
AD Connector	Proxy that redirects auth requests to on-prem AD	Want to use existing on-prem AD without syncing data to AWS. Requires VPN/DX connectivity.
Simple AD	Samba-based lightweight directory	Small workloads (<500 users), don’t need advanced AD features or trust relationships.

Common Architecture Patterns

Pattern 1: Enterprise Workforce (Multi-Account)

On-prem AD → AWS Managed Microsoft AD (trust) or AD Connector → IAM Identity Center → Permission Sets per account → Users get SSO portal access to all accounts.

Pattern 2: Customer-Facing App

User → Cognito User Pool (sign-up/sign-in/MFA) → JWT → API Gateway (Cognito Authorizer) → Lambda → DynamoDB. Social login via Cognito federated identities.

Pattern 3: CI/CD Pipeline (No Credentials)

GitHub Actions → OIDC Provider in AWS → AssumeRoleWithWebIdentity → temporary credentials → deploy to AWS. No IAM access keys stored in GitHub.

Pattern 4: On-Premises Servers

On-prem server → X.509 certificate → IAM Roles Anywhere → temporary STS credentials → access AWS services. Eliminates long-term access keys.

Exam Tips

Exam	Key Points
SCS-C03	“Workforce SSO to multiple accounts” → IAM Identity Center. “Customer sign-up/sign-in” → Cognito User Pools. “Mobile app needs AWS credentials” → Cognito Identity Pools. “On-prem AD + AWS console” → AD Connector or Managed AD + Identity Center. “Social login” → Cognito User Pools (hosted UI). “CI/CD without access keys” → OIDC Provider. “On-prem server needs AWS access” → IAM Roles Anywhere.

AWS Certification Exam Practice Questions

Question 1:

A company with 2,000 employees uses on-premises Active Directory. They need employees to access multiple AWS accounts through a single portal using their existing AD credentials, without creating IAM users. Which solution provides this?

1. Create IAM users in each account matching AD usernames with the same passwords
2. Set up IAM Identity Center with AD Connector (or AWS Managed Microsoft AD with trust), create permission sets for each account
3. Create a Cognito User Pool and import all AD users
4. Set up SAML federation directly in each AWS account’s IAM

Show Answer

Answer: B — IAM Identity Center provides a single SSO portal for all accounts. Connect it to on-prem AD via AD Connector (if you don’t need AD in AWS) or via Managed Microsoft AD with a trust relationship. Permission sets define what each group can do in each account. One portal, one login, access to all accounts. Direct SAML per account (D) works but requires configuration in each account separately (doesn’t scale).

Question 2:

A mobile application needs users to sign up with email, sign in with MFA, and then directly upload files to an S3 bucket scoped to their user ID. No server-side proxy should be involved in the upload. Which Cognito architecture achieves this?

1. User Pool only — authenticate, get JWT, use JWT to access S3 directly
2. User Pool (auth) + Identity Pool (exchange JWT for AWS credentials with IAM role that has S3 access scoped to ${cognito-identity.amazonaws.com:sub})
3. Identity Pool only with unauthenticated access to S3
4. User Pool with Lambda trigger that generates pre-signed S3 URLs

Show Answer

Answer: B — User Pool handles authentication (sign-up, MFA). Identity Pool exchanges the JWT for temporary AWS credentials (STS). The IAM role’s policy uses ${cognito-identity.amazonaws.com:sub} as a variable to scope S3 access to that user’s prefix. The mobile app gets AWS credentials and uploads directly to S3. JWTs (A) cannot directly authenticate to S3. Pre-signed URLs (D) require a server-side component.

Question 3:

A company’s GitHub Actions CI/CD pipeline needs to deploy to AWS. The security team prohibits storing long-term AWS access keys in GitHub. Which approach eliminates the need for stored credentials?

1. Store access keys in GitHub Secrets (encrypted at rest)
2. Configure an IAM OIDC identity provider for GitHub, create a role trusting GitHub’s OIDC provider with conditions on repository/branch
3. Use AWS CodePipeline instead of GitHub Actions
4. Create a dedicated IAM user with minimal permissions and rotate keys weekly

Show Answer

Answer: B — IAM OIDC provider for GitHub allows GitHub Actions to call AssumeRoleWithWebIdentity using GitHub’s OIDC token. AWS verifies the token and returns temporary credentials. No long-term keys stored anywhere. The role trust policy can restrict to specific repos/branches using conditions. GitHub Secrets (A) still stores credentials. Rotating keys (D) is better than static but still stores keys.

Question 4:

A company needs their application to support both enterprise SSO (employees via corporate SAML) and social login (customers via Google/Facebook). All users access the same application but get different permissions. Which architecture supports both?

1. Two separate applications — one using IAM Identity Center, one using Cognito
2. Single Cognito User Pool configured with SAML federation for enterprise IdP AND social identity providers (Google, Facebook). Use groups for different permissions.
3. IAM Identity Center for both enterprise and social users
4. Custom Lambda-based authentication handling both protocols

Show Answer

Answer: B — Cognito User Pools support multiple identity providers simultaneously: SAML (for enterprise IdP), OIDC (social providers), plus native email/password. Users from all sources land in the same user pool. Groups and custom attributes differentiate permissions (enterprise users get admin group, social users get customer group). IAM Identity Center (C) is for AWS console access, not application auth.

Question 5:

A company uses AWS Managed Microsoft AD with a two-way trust to their on-premises AD. They want to ensure that on-premises AD users can authenticate to AWS services (WorkSpaces, RDS SQL Server), but AWS-managed AD users cannot access on-premises resources. Which trust configuration is correct?

1. Two-way trust (already configured — correct as-is)
2. Replace with one-way trust: on-premises AD trusts AWS Managed AD (forest trust direction)
3. Replace with one-way trust: AWS Managed AD trusts on-premises AD
4. Remove the trust and use AD Connector instead

Show Answer

Answer: C — Trust direction is counterintuitive: the trusting domain allows users from the trusted domain to access its resources. AWS Managed AD trusts on-prem AD = on-prem users CAN access AWS resources. On-prem AD does NOT trust AWS AD = AWS users CANNOT access on-prem resources. A two-way trust (A) would allow both directions. AD Connector (D) is a proxy, not a replacement for Managed AD features.

Related Posts

• IAM Security Architecture
• Multi-Account Architecture
• Zero Trust Architecture
• Secrets & Certificate Management

References

• IAM Identity Center User Guide
• Amazon Cognito Developer Guide
• GitHub Actions OIDC Federation — AWS Blog
• AWS Directory Service Guide

Frequently Asked Questions

IAM Identity Center vs Cognito — when to use which?

IAM Identity Center: For workforce (employees) accessing AWS accounts and business applications. Provides SSO portal, permission sets, multi-account access. Cognito: For customers/end-users accessing YOUR application. Provides sign-up/sign-in, social login, MFA, JWT tokens. Never use Identity Center for customer-facing apps. Never use Cognito for AWS console access.

What is the difference between Cognito User Pools and Identity Pools?

User Pools = Authentication (who are you?). Manages user directory, sign-up/sign-in, MFA, password policies. Outputs JWT tokens. Identity Pools = Authorization (what can you do?). Exchanges tokens (from User Pool, Google, Facebook) for temporary AWS credentials. Outputs AWS access keys. Use User Pools alone for API Gateway auth. Add Identity Pools when the client needs direct AWS service access.

AD Connector vs AWS Managed Microsoft AD?

AD Connector: Lightweight proxy that redirects authentication to your existing on-prem AD. No data stored in AWS. Requires VPN/DX connectivity. Cannot run AD-aware workloads. Managed Microsoft AD: Full AD running in AWS (2 domain controllers). Supports trusts, Group Policy, AD-aware apps (SQL Server Windows Auth). Choose Managed AD when you need AD features in AWS. Choose AD Connector when you just need auth proxying.