Study guide
Technical reference and lesson notes
This lesson explains how AWS supports identity federation, where users authenticate through an existing identity source instead of being created directly as IAM users. This is important for the SAP-C02 exam because many enterprise architecture scenarios involve connecting corporate identity systems, SaaS identity providers, mobile apps, or web applications to AWS securely.
The core exam idea is this: AWS generally does not want long-term credentials embedded in applications or manually managed across many users. Instead, AWS expects federated identities to receive temporary credentials through AWS Security Token Service.
Key Concepts
What Identity Federation Means in AWS
Identity federation allows users to authenticate with an external identity source and then access AWS resources without needing a separate AWS IAM user account.
For example, a company may already store user identities in:
- On-premises Microsoft Active Directory
- Microsoft Entra ID / Azure AD
- Okta
- Ping Identity
- Apple
- Another SAML 2.0 or OpenID Connect compatible provider
Instead of recreating those users in IAM, AWS can trust the external identity provider and issue temporary AWS credentials after successful authentication.
The major benefit is centralized identity management. Users keep one identity, one password policy, one MFA configuration, and one lifecycle process. When the user leaves the company, disabling the external account also removes their ability to federate into AWS.
Identity Store vs Identity Provider
A common exam distinction is the difference between an identity store and an identity provider.
An identity store is where the users and credentials live. Microsoft Active Directory is a common example. It stores usernames, passwords, group memberships, and other identity attributes.
An identity provider, or IdP, is the system that performs or brokers authentication and sends proof of that authentication to another system. In a Microsoft environment, Active Directory Federation Services, or ADFS, can act as the identity provider.
In an AWS federation flow, the IdP does not directly give users AWS permissions. Instead, it proves that the user authenticated successfully. AWS then maps that authentication result to an IAM role and issues temporary credentials.
AWS STS and Temporary Credentials
AWS Security Token Service, or AWS STS, is central to federation.
STS issues temporary security credentials that can be used to access AWS services. These credentials are time-limited and are typically associated with an IAM role.
Temporary credentials are preferred because they reduce the risk associated with long-lived access keys. If temporary credentials are exposed, they expire automatically. Long-term IAM access keys remain valid until manually rotated or deleted.
For the SAP-C02 exam, remember that federation usually involves:
- User authenticates with an external identity provider.
- Identity provider returns a token or assertion.
- AWS STS validates that proof through a trusted relationship.
- STS issues temporary AWS credentials.
- The user or application uses those temporary credentials to access AWS resources.
SAML Federation with Active Directory or Enterprise IdPs
SAML federation is commonly used for workforce access.
A typical enterprise pattern looks like this:
- Users are stored in Active Directory.
- ADFS or another SAML 2.0 identity provider authenticates the user.
- The IdP returns a SAML assertion.
- The application or sign-in flow sends that assertion to AWS STS.
- AWS STS uses
AssumeRoleWithSAML. - STS returns temporary credentials for an IAM role.
- The user or application accesses AWS resources based on that role’s permissions.
The important API call is:
AssumeRoleWithSAML
This is used when the user has authenticated through a SAML 2.0 identity provider.
Example Scenario
A corporate user signs in with their Active Directory credentials. They need access to an AWS service such as DynamoDB. Active Directory can authenticate the user, but it does not automatically authorize access to DynamoDB.
The SAML federation layer bridges that gap. AWS trusts the SAML assertion, maps the user to an IAM role, and STS issues temporary credentials that allow access to the DynamoDB table.
Web Identity Federation
Web Identity Federation allows users to authenticate through web-based identity providers such as:
- Apple
- Any OpenID Connect compatible provider
The important AWS STS API call is:
AssumeRoleWithWebIdentity
This differs from SAML federation. SAML is more common in enterprise workforce scenarios, while web identity federation is commonly associated with consumer-facing web or mobile apps.
However, for modern AWS architectures, AWS generally expects you to use Amazon Cognito for most web and mobile application authentication scenarios instead of building directly against web identity federation yourself.
IAM Identity Center
AWS IAM Identity Center is the AWS service used for centralized workforce access management across AWS accounts and applications. It was formerly called AWS Single Sign-On.
IAM Identity Center provides:
- Centralized user access management
- Single sign-on into AWS accounts
- Integration with AWS Organizations
- Permission sets that map to roles in AWS accounts
- Support for external identity providers using SAML 2.0
- Built-in integrations with many business applications
IAM Identity Center can use several identity sources, including:
- The built-in IAM Identity Center identity store
- AWS Managed Microsoft AD
- AD Connector
- External SAML 2.0 identity providers such as Microsoft Entra ID or Okta
For multi-account environments, IAM Identity Center is usually the preferred design pattern for workforce access because it integrates with AWS Organizations and lets you manage access centrally instead of manually configuring roles in each AWS account.
IAM Identity Center and AWS Organizations
IAM Identity Center becomes especially powerful when connected to AWS Organizations.
In a professional-level architecture, you may have many AWS accounts for:
- Production
- Development
- Testing
- Security tooling
- Logging
- Shared services
- Networking
- Sandbox workloads
Without centralized access management, each account could become difficult to govern. IAM Identity Center lets you assign users or groups to accounts with specific permission sets.
For example:
| User Group | AWS Account | Permission Set |
|---|---|---|
| Cloud Admins | Management / Shared Services | AdministratorAccess |
| Developers | Dev Account | PowerUserAccess |
| Security Team | Log Archive / Security Account | SecurityAudit |
| Finance | Billing Account | Billing access |
Behind the scenes, IAM Identity Center creates and manages the roles needed in target accounts.
Amazon Cognito
Amazon Cognito is designed for customer-facing web and mobile applications.
Cognito has two major components that are important for this lesson:
| Cognito Component | Purpose |
|---|---|
| Cognito User Pool | Authenticates users |
| Cognito Identity Pool | Exchanges identity tokens for temporary AWS credentials |
Cognito User Pools
A Cognito User Pool is a user directory and authentication service.
It can:
- Store users directly in Cognito
- Allow sign-up and sign-in
- Integrate with social identity providers
- Integrate with external SAML or OIDC providers
- Return tokens after authentication
After a user authenticates, Cognito returns tokens such as a JSON Web Token, commonly abbreviated as JWT.
Cognito Identity Pools
A Cognito Identity Pool is used to provide temporary AWS credentials to users.
The identity pool can take a token from a user pool or external IdP and exchange it for AWS credentials through STS.
This allows a mobile or web app to access AWS services such as:
- DynamoDB
- S3
- API Gateway-backed services
- AppSync
- Other services permitted by the associated IAM role
The key design point is that the application does not store permanent AWS credentials. It receives temporary credentials scoped to an IAM role.
Cognito vs IAM Identity Center
These services are often confused, but they solve different problems.
| Service | Primary Use Case |
|---|---|
| IAM Identity Center | Workforce access to AWS accounts and business applications |
| Amazon Cognito | Customer/user authentication for web and mobile applications |
| SAML Federation with STS | Enterprise federation into AWS roles |
| Web Identity Federation | Direct federation using social/OIDC providers, though Cognito is usually preferred |
Use IAM Identity Center when employees, contractors, administrators, developers, or internal teams need access to AWS accounts.
Use Cognito when application users need to sign in to a web or mobile app.
Exam-Relevant Takeaways
For SAP-C02, the main thing to remember is that federation avoids creating separate IAM users for everyone.
In enterprise environments, users should authenticate through a centralized identity provider. AWS then grants access using IAM roles and temporary STS credentials.
Remember these mappings:
| Federation Type | Token or Assertion | AWS API / Service | Common Use Case |
|---|---|---|---|
| SAML federation | SAML assertion | AssumeRoleWithSAML | Corporate workforce federation |
| Web identity federation | OIDC/social identity token | AssumeRoleWithWebIdentity | Social or OIDC-based app access |
| Cognito | JWT / identity token | Cognito Identity Pool + STS | Web/mobile app users accessing AWS |
| IAM Identity Center | External IdP or internal identity store | Permission sets and account assignments | Multi-account workforce access |
Temporary credentials are a recurring exam theme. If an answer involves storing long-term access keys in a mobile app, web app, EC2 instance, or corporate application, it is usually not the best answer.
Architecture Decision Guide
| Scenario | Best AWS Choice | Why |
|---|---|---|
| Employees need access to multiple AWS accounts in AWS Organizations | IAM Identity Center | Centralized workforce access management with permission sets and account assignments |
| Company uses Microsoft Entra ID, Okta, or another SAML provider for employee login | IAM Identity Center or SAML federation | Allows existing identities and MFA policies to control AWS access |
| On-premises Active Directory users need federated access to AWS | SAML federation using ADFS or IAM Identity Center with AD integration | Avoids separate IAM users and supports enterprise SSO |
| Mobile app users need to sign in with Google, Apple, or Facebook | Amazon Cognito | Purpose-built for web/mobile authentication and token handling |
| Mobile app needs temporary AWS credentials to access DynamoDB | Cognito Identity Pool | Exchanges authenticated user identity for temporary AWS credentials |
| Application needs direct SAML-based role assumption | STS AssumeRoleWithSAML | Used when a SAML assertion is exchanged for AWS role credentials |
| Application uses OIDC or social identity token directly | STS AssumeRoleWithWebIdentity | Used for web identity federation, though Cognito is usually the preferred pattern |
| Organization wants one place to manage AWS account access | IAM Identity Center | Reduces per-account IAM role/user sprawl |
| Consumer-facing app needs a user directory | Cognito User Pool | Handles user registration, sign-in, and token issuance |
| App already authenticated a user and now needs AWS service access | Cognito Identity Pool | Provides temporary AWS credentials based on the authenticated identity |
Common Exam Traps
Trap 1: Creating IAM Users for Corporate Employees
A scenario may describe a company with Active Directory or an existing identity provider and then offer an answer that creates IAM users for every employee.
That is usually not the best architecture.
For enterprise workforce access, prefer federation through IAM Identity Center or SAML-based role assumption.
Trap 2: Storing AWS Access Keys in a Mobile App
Mobile apps should not contain long-term AWS credentials.
For mobile and web apps, the better pattern is usually:
Cognito User Pool → Cognito Identity Pool → STS temporary credentials → AWS service access
Trap 3: Confusing Cognito User Pools and Identity Pools
User Pools authenticate users.
Identity Pools authorize access to AWS resources by exchanging identity tokens for temporary AWS credentials.
A User Pool alone does not directly grant AWS permissions to DynamoDB, S3, or other AWS services.
Trap 4: Using Web Identity Federation When Cognito Is the Better Fit
Direct web identity federation exists, but for most web and mobile app scenarios, Amazon Cognito is the more complete managed service.
If the scenario involves social login for a mobile or web application, Cognito is usually the exam-friendly answer.
Trap 5: Thinking Active Directory Permissions Apply Directly to AWS
Active Directory can authenticate users and contain group memberships, but it does not directly authorize access to AWS services like DynamoDB or S3.
AWS authorization still comes from IAM policies attached to IAM roles.
Trap 6: Forgetting STS
Federation almost always comes back to temporary credentials.
When AWS needs to let an external identity access AWS resources, STS is commonly involved.
Real-World Engineer Notes
In a real enterprise, identity federation is both a security and operational control.
From an operations standpoint, centralized identity reduces duplicate account management. If users are created manually in IAM, onboarding, offboarding, access reviews, MFA enforcement, and password policies become harder to govern.
From a security standpoint, temporary credentials are much safer than long-lived access keys. You do not want access keys stored in app code, mobile clients, local config files, or shared scripts unless there is a very specific and controlled reason.
For multi-account AWS environments, IAM Identity Center should usually be part of the landing zone conversation. If the company is using AWS Organizations, Control Tower, or a multi-account strategy, IAM Identity Center provides cleaner access governance than creating IAM users in each account.
For application teams, Cognito requires careful design. You need to decide whether Cognito stores the users directly or federates to social or enterprise IdPs. You also need to decide what AWS resources the app users can access and how IAM roles are mapped to authenticated or unauthenticated identities.
In troubleshooting scenarios, it helps to separate the problem into layers:
| Layer | Troubleshooting Focus |
|---|---|
| Identity source | Does the user exist, and are credentials/MFA working? |
| Identity provider | Is the SAML/OIDC token being issued correctly? |
| AWS trust relationship | Does AWS trust the IdP and allow role assumption? |
| STS | Are temporary credentials being issued? |
| IAM role permissions | Does the role allow the requested AWS action? |
| Resource policy | Does the target resource allow access? |
In real environments, many federation issues are not caused by AWS service outages. They are often caused by mismatched SAML attributes, expired certificates, incorrect role trust policies, missing group mappings, or permission set misconfiguration.
Quick Reference Summary
Identity federation lets external users access AWS without creating IAM users for each person.
AWS STS issues temporary credentials.
SAML federation commonly uses AssumeRoleWithSAML.
Web identity federation uses AssumeRoleWithWebIdentity.
IAM Identity Center is best for centralized workforce access across AWS accounts and business applications.
Amazon Cognito is best for customer-facing web and mobile applications.
Cognito User Pools authenticate users.
Cognito Identity Pools provide temporary AWS credentials.
For multi-account AWS environments, IAM Identity Center plus AWS Organizations is the preferred workforce access pattern.
For mobile apps, avoid hardcoded AWS keys. Use Cognito and temporary credentials.
Flashcards
Q: What is identity federation in AWS?
A: Identity federation allows users to authenticate through an external identity source or identity provider and receive access to AWS resources through temporary credentials instead of separate IAM users.
Q: What AWS service issues temporary security credentials?
A: AWS Security Token Service, or AWS STS.
Q: Which STS API is used with SAML federation?
A: AssumeRoleWithSAML.
Q: Which STS API is used with web identity federation?
A: AssumeRoleWithWebIdentity.
Q: What is the main use case for IAM Identity Center?
A: Centralized workforce access management for AWS accounts and business applications.
Q: What was IAM Identity Center formerly called?
A: AWS Single Sign-On, or AWS SSO.
Q: What AWS service is commonly used for authentication in web and mobile applications?
A: Amazon Cognito.
Q: What does a Cognito User Pool do?
A: It authenticates users and acts as a user directory.
Q: What does a Cognito Identity Pool do?
A: It exchanges authenticated identity tokens for temporary AWS credentials.
Q: What kind of token can Cognito return after authentication?
A: A JSON Web Token, or JWT.
Q: Should mobile applications store long-term AWS access keys?
A: No. They should use services such as Cognito and STS to obtain temporary credentials.
Q: What is the role of a SAML assertion?
A: It proves that a user authenticated successfully with a SAML identity provider.
Q: In AWS, what ultimately controls what a federated user can access?
A: IAM roles, IAM policies, and any applicable resource policies.
Q: When should you choose Cognito instead of IAM Identity Center?
A: Choose Cognito for customer-facing web or mobile app authentication. Choose IAM Identity Center for workforce access to AWS accounts.
Q: Why is federation preferred over creating IAM users for every employee?
A: Federation centralizes identity management, simplifies offboarding, supports existing MFA policies, and avoids long-term IAM credentials.
Practice Questions
Question 1:
A company uses on-premises Active Directory for employee identities. Employees need access to AWS resources without creating separate IAM users. The company wants users to authenticate with their existing corporate credentials and receive temporary AWS access.
Which approach is most appropriate?
A. Create IAM users for each employee and assign access keys
B. Store Active Directory credentials in AWS Secrets Manager
C. Use SAML federation with AWS STS AssumeRoleWithSAML
D. Create a Cognito User Pool for all employees and store their passwords there
Correct Answer:
C. Use SAML federation with AWS STS AssumeRoleWithSAML
Explanation:
For enterprise workforce federation with Active Directory or ADFS, SAML federation allows users to authenticate through the corporate identity provider and receive temporary AWS credentials through STS.
Question 2:
A mobile application allows users to sign in with Google or Apple. After signing in, the app needs temporary access to a DynamoDB table. The company does not want to embed AWS access keys in the application.
Which design is the best fit?
A. Store an IAM user access key in the mobile app
B. Use Amazon Cognito with a User Pool and Identity Pool
C. Create one IAM user for each mobile app user
D. Use AWS Organizations to assign the mobile users to AWS accounts
Correct Answer:
B. Use Amazon Cognito with a User Pool and Identity Pool
Explanation:
Cognito is designed for web and mobile application authentication. A User Pool can authenticate users, and an Identity Pool can exchange tokens for temporary AWS credentials.
Question 3:
An architect is designing access for developers across several AWS accounts in an AWS Organizations environment. The company wants centralized access control and single sign-on using its existing external identity provider.
Which AWS service should be prioritized?
A. Amazon Cognito
B. IAM Identity Center
C. AWS Secrets Manager
D. AWS Directory Service Simple AD only
Correct Answer:
B. IAM Identity Center
Explanation:
IAM Identity Center is the preferred service for centralized workforce access across multiple AWS accounts, especially when integrated with AWS Organizations and an external identity provider.
Question 4:
A developer says that Cognito User Pools and Cognito Identity Pools perform the same function. What is the correct clarification?
A. User Pools authorize access to AWS resources, while Identity Pools authenticate users
B. User Pools authenticate users, while Identity Pools provide temporary AWS credentials
C. Both are only used for SAML federation into AWS accounts
D. Both are used only for IAM Identity Center permission sets
Correct Answer:
B. User Pools authenticate users, while Identity Pools provide temporary AWS credentials
Explanation:
A Cognito User Pool handles authentication and token issuance. A Cognito Identity Pool exchanges identity tokens for temporary AWS credentials.
Question 5:
A solution uses a SAML identity provider to authenticate users. After authentication, AWS STS issues temporary credentials for an IAM role. What determines the AWS actions the user can perform?
A. The user’s Active Directory password policy
B. The IAM role permissions and applicable resource policies
C. The name of the SAML identity provider only
D. The user’s local workstation permissions
Correct Answer:
B. The IAM role permissions and applicable resource policies
Explanation:
The external identity provider authenticates the user, but AWS authorization is controlled by IAM policies attached to the assumed role and any relevant resource policies.