This chapter covers AWS Identity Federation and Single Sign-On (SSO), a critical security domain for the CLF-C02 exam. You'll learn how to grant external users access to AWS resources without creating IAM users, and how to centralize access management across multiple accounts. This objective falls under Domain 2: Security and Compliance, which carries approximately 25% of the exam weight. Understanding federation is essential for passing the exam and for real-world AWS security architecture.
Jump to a section
Imagine you work for a large company that uses a third-party security firm to issue employee badges. Instead of your company managing its own badge system, it trusts the security firm to verify your identity. When you enter the office, you scan your badge at the door. The door doesn't check your ID itself; it trusts the security firm's assertion that you are who you say you are. This is federation. In AWS, identity federation lets users authenticate using an external identity provider (IdP) like Active Directory, Google, or Facebook. AWS Identity and Access Management (IAM) acts as the door: it trusts the IdP's token (the badge). The user never needs an IAM user password; they get temporary credentials via AWS Security Token Service (STS). The key mechanism: the IdP issues a SAML 2.0 assertion or an OIDC token, which the user presents to AWS STS. STS validates the token against the trusted IdP and returns temporary AWS credentials (access key, secret key, session token) with permissions defined by an IAM role. The user then uses those credentials to call AWS APIs. The IdP manages user lifecycle—hiring, firing, role changes—while AWS only sees temporary credentials, reducing administrative overhead and improving security. Single sign-on (SSO) extends this: after one login to the corporate portal, the user can access multiple AWS accounts or business applications without re-entering credentials. AWS IAM Identity Center (successor to AWS SSO) is the central place to manage SSO across accounts and applications.
What is Identity Federation and Why Does It Matter?
Identity federation is a mechanism that allows users to access AWS resources using identities managed outside of AWS. Instead of creating and managing IAM users in every AWS account, you can rely on an external identity provider (IdP) that your organization already uses, such as Microsoft Active Directory, Okta, or any SAML 2.0 or OpenID Connect (OIDC) compatible provider. This solves a fundamental problem: in an enterprise with thousands of employees, managing IAM users across multiple accounts is impractical and insecure. Federation enables a single corporate identity to access multiple AWS accounts and applications without needing separate passwords or AWS credentials.
How Federation Works: The Mechanism
The core mechanism involves four parties: the user, the identity provider (IdP), AWS Security Token Service (STS), and IAM roles. Here's the step-by-step flow:
User authenticates to IdP: The user logs into their corporate directory (e.g., Active Directory) using their existing credentials (username/password, smart card, etc.). The IdP verifies the user's identity.
IdP generates a token: After successful authentication, the IdP creates a security token that asserts the user's identity and attributes (like group membership). For SAML 2.0, this is a SAML assertion; for OIDC, it's a JSON Web Token (JWT).
User presents token to AWS STS: The user (or an application on their behalf) sends the token to the AWS STS AssumeRoleWithSAML or AssumeRoleWithWebIdentity API endpoint. The request includes the token and the ARN of the IAM role the user wants to assume.
STS validates the token: STS checks that the token is cryptographically signed by a trusted IdP (configured as an IAM identity provider in AWS). It also verifies the token's expiration and audience.
STS returns temporary credentials: If valid, STS returns a temporary set of AWS credentials (access key ID, secret access key, session token) that are valid for a configurable duration (default 1 hour, max 12 hours for SAML, 1 hour for web identity). These credentials are scoped to the permissions of the IAM role the user assumed.
User accesses AWS resources: The user uses the temporary credentials to make AWS API calls. They can interact with the AWS Management Console, CLI, or SDKs. The credentials automatically expire, requiring re-authentication.
Key Components: IAM Identity Provider, IAM Roles, and STS
IAM Identity Provider: This is an IAM resource that represents the external IdP. You create an IAM identity provider for SAML or OIDC. For SAML, you upload the IdP's metadata document (containing the public key and endpoints). For OIDC, you provide the issuer URL, audience, and thumbprint.
IAM Roles: You create an IAM role with a trust policy that allows the identity provider (and optionally specific conditions like saml:sub or aud) to assume the role. The role's permissions policy defines what the federated user can do. The trust policy is critical: it specifies the Principal as the identity provider ARN and the Action as sts:AssumeRoleWithSAML or sts:AssumeRoleWithWebIdentity.
AWS Security Token Service (STS): A global service that issues temporary credentials. It has endpoints in every region. You can use global endpoint (sts.amazonaws.com) or regional endpoints to reduce latency. STS is free to use, but there are API request limits (default 1000 requests per second per account).
SAML 2.0 vs. OpenID Connect (OIDC)
SAML 2.0 is the older, XML-based protocol widely used in enterprise. OIDC is a modern, RESTful protocol built on OAuth 2.0, using JSON. The exam expects you to know the difference:
SAML 2.0: Used for enterprise federation with Active Directory Federation Services (ADFS), Okta, Shibboleth. It supports attribute-based access control (ABAC) via SAML attributes. The token is an XML assertion.
OIDC: Used for web identity federation with Google, Facebook, Amazon, or any OIDC-compatible IdP. Also used for CI/CD tools like GitHub Actions. The token is a JWT. OIDC is simpler and more scalable for consumer-facing apps.
AWS IAM Identity Center (Successor to AWS SSO)
AWS IAM Identity Center (formerly AWS Single Sign-On) is a managed service that simplifies federation across multiple AWS accounts and business applications. It can use an external IdP (like Okta or Azure AD) or its own built-in identity store. Key features:
Multi-account access: You can grant users access to multiple AWS accounts from a single login. Users see a portal (https://<your-alias>.awsapps.com/start) listing all accounts and roles they can access.
Application access: Supports SAML 2.0 applications like Salesforce, Office 365, and custom apps.
Permission sets: A permission set is a collection of IAM policies that you assign to users/groups for specific accounts. It's similar to an IAM role but managed centrally.
Attribute-based access control (ABAC): You can use user attributes (e.g., cost center, job code) from the IdP to dynamically control permissions.
Audit and logging: All sign-in events are logged to AWS CloudTrail for auditing.
Pricing and Limits
IAM Identity Center: Free to use. You pay only for AWS resources accessed by users (e.g., EC2 instances, S3 storage).
STS: Free, but with API rate limits.
IAM roles: No additional cost.
IAM identity providers: No cost.
Comparison to On-Premises
In on-premises environments, you typically have a single Active Directory domain where all users and permissions are managed. In AWS, without federation, you would need to create IAM users in each account and manage passwords/access keys. This becomes unmanageable at scale. Federation brings the on-premises model to the cloud: one identity source, centralized access control, and automatic credential rotation.
When to Use Federation vs. Alternatives
Use federation when: You have an existing corporate directory (e.g., Active Directory) and want to give employees access to AWS without creating IAM users. Also for customer-facing applications where users sign in with Google or Facebook.
Use IAM users when: You have a small number of users (e.g., under 10) who need programmatic access (access keys) and don't have an external IdP. Also for service accounts (e.g., a CI/CD pipeline) that need long-term credentials (though best practice is to use IAM roles).
Use IAM Identity Center when: You need to manage access to multiple AWS accounts and SAML applications from a single place. It's the recommended approach for workforce identity (employees).
Use Cognito when: You need user pools for customer-facing applications with sign-up/sign-in, social identity providers, or Amazon Cognito user pools as an IdP.
Key Exam Points
The CLF-C02 exam tests your understanding of the federation concept, not deep configuration. You need to know what federation is, why it's used, and the difference between SAML and OIDC.
You must know that federation uses temporary credentials from STS, never long-term access keys.
Understand that IAM Identity Center is the AWS managed SSO service.
Know that you cannot use IAM roles for federation without a trust policy that references the identity provider.
Be aware that AWS Organizations is often used with IAM Identity Center to centrally manage permissions across accounts.
Configure IAM Identity Center
Navigate to the AWS IAM Identity Center console. If you haven't enabled it, click 'Enable' (it's free). During setup, you choose your identity source: either the built-in identity store (AWS-managed) or an external IdP like Okta, Azure AD, or OneLogin. For external IdP, you provide the SAML metadata or OIDC details. IAM Identity Center creates a portal URL (e.g., https://d-12345.awsapps.com/start). This is where users will log in. Behind the scenes, IAM Identity Center registers itself as a SAML application with your IdP. The portal URL is unique per AWS account and cannot be customized except for the alias (e.g., your-company.awsapps.com).
Create Permission Sets
A permission set defines the level of access a user or group gets in an AWS account. In the IAM Identity Center console, go to 'Permission sets' and click 'Create permission set'. You can choose from predefined policies (e.g., AdministratorAccess, PowerUserAccess, ReadOnlyAccess) or create a custom policy by pasting a JSON policy document. Each permission set is essentially an IAM role, but it's managed centrally. You can also configure session duration (1 to 12 hours) and whether users can set a custom session duration. Permission sets are reusable across accounts.
Assign Users and Groups to Accounts
In IAM Identity Center, go to 'AWS accounts' and select the account(s) you want to grant access to. Click 'Assign users or groups'. You can assign individual users or groups from your identity source. Then select one or more permission sets. This creates an IAM role in the target account with a trust policy that allows IAM Identity Center to assume it. The role name is auto-generated (e.g., AWSReservedSSO_<PermissionSetName>_<Random>). Users will see these roles in their portal. You cannot manually modify these roles; they are managed by IAM Identity Center.
User Logs In via Portal
The user navigates to the IAM Identity Center portal URL. They authenticate using their corporate credentials (e.g., Okta login). After successful authentication, the portal displays all AWS accounts and roles (permission sets) assigned to them. The user clicks on an account and then selects a role. This triggers a SAML assertion exchange: the portal sends a SAML request to AWS STS, which validates it and returns temporary credentials. The user is then redirected to the AWS Management Console with those credentials. The session duration is set by the permission set (default 1 hour).
Access AWS Resources
Once the user is in the AWS Management Console, they can perform actions allowed by the permission set's IAM policies. For example, if assigned ReadOnlyAccess, they can list S3 buckets but not delete objects. The temporary credentials are valid for the session duration. When the session expires, the user must log in again. For programmatic access (CLI/SDK), the user can retrieve temporary credentials from the portal via the 'Command line or programmatic access' option. This provides access key, secret key, and session token valid for the same duration.
Scenario 1: Enterprise with Active Directory Federation
A large enterprise with 10,000 employees uses Microsoft Active Directory on-premises. They have 50 AWS accounts managed via AWS Organizations. Without federation, they would need to create 10,000 IAM users across 50 accounts, resulting in 500,000 IAM users — impossible to manage. They deploy IAM Identity Center with Active Directory as the identity source via AD Connector or AWS Managed Microsoft AD. They create permission sets like 'Developer', 'Admin', and 'ReadOnly'. Developers get access to development accounts with EC2 and S3 permissions. Admins get full access to all accounts. The HR system manages user provisioning: when an employee leaves, their AD account is disabled, and within minutes they lose all AWS access. This solves the problem of manual IAM user management and reduces security risk from stale credentials.
Scenario 2: Startup with Google Workspace
A startup uses Google Workspace for email and identity. They have a single AWS account. They want employees to use their Google credentials to access the AWS Management Console and CLI. They configure IAM Identity Center with Google Workspace as the external IdP using OIDC. They create a permission set with 'PowerUserAccess' for engineers and 'ReadOnlyAccess' for others. Employees log in via Google SSO and see the AWS console. The startup avoids creating IAM users and benefits from Google's MFA. When an employee leaves, the Google admin revokes access, and AWS access is automatically removed. Cost: IAM Identity Center is free; they only pay for Google Workspace and AWS resources.
Misconfiguration Pitfalls
A common mistake is failing to configure the trust policy correctly in the IAM role for SAML federation. For example, setting Action: sts:AssumeRoleWithSAML but forgetting to specify the SAML:aud condition, which allows any user from the IdP to assume the role. This leads to privilege escalation. Another pitfall: not setting a session duration limit, resulting in long-lived sessions that increase risk. Also, if the IdP metadata is not updated when the certificate expires, federation breaks. In production, teams should automate IdP metadata refresh and monitor CloudTrail for AssumeRoleWithSAML failures.
What CLF-C02 Tests on This Objective
The exam objective '2.2: Explain the shared responsibility model' includes identity federation as a key concept. You will be asked to identify scenarios where federation is appropriate, differentiate between federation methods, and recognize the benefits. The exam does NOT require you to configure federation, but you must understand the high-level flow.
Common Wrong Answers and Why
'Federation creates IAM users in the account.' — Wrong. Federation does not create IAM users. It uses temporary credentials from STS. Candidates confuse federated users with IAM users.
'You can use federation with any identity provider, including Facebook, without configuration.' — Wrong. You must create an IAM identity provider and configure trust. Facebook is supported via OIDC, but you still need to set up the provider.
'IAM Identity Center requires an external IdP.' — Wrong. It has its own built-in identity store. You can use it without any external IdP.
'Federation is only for human users, not applications.' — Wrong. Applications can use web identity federation (e.g., Cognito) or OIDC for machine-to-machine access.
Specific Terms That Appear Verbatim
AssumeRoleWithSAML
AssumeRoleWithWebIdentity
SAML 2.0 assertion
OIDC token
IAM identity provider
Permission set (in IAM Identity Center)
AWS SSO (old name, but still might appear; note it's now IAM Identity Center)
Tricky Distinctions
Federation vs. IAM users: Federation uses temporary credentials; IAM users have long-term credentials (access keys). Federation is preferred for human users.
SAML vs. OIDC: SAML is XML-based, often used with enterprise IdPs; OIDC is JSON-based, used with social IdPs and modern apps.
IAM Identity Center vs. Cognito: IAM Identity Center is for workforce (employees); Cognito is for customer-facing apps.
Decision Rule for Multiple Choice
If a question asks about giving employees access to AWS using their existing corporate credentials, the answer is federation with SAML 2.0 or IAM Identity Center. If it asks about giving customers access via Google login, the answer is web identity federation (OIDC) or Amazon Cognito. If it mentions 'temporary credentials' and 'role assumption', the answer is STS federation. Eliminate any answer that mentions creating IAM users or long-term access keys.
Identity federation allows users to access AWS using external identities, avoiding IAM user creation.
Federation uses AWS STS to issue temporary credentials (access key, secret key, session token).
Two main protocols: SAML 2.0 (enterprise) and OIDC (web/mobile).
IAM Identity Center is the AWS managed SSO service for workforce identity across multiple accounts.
Permission sets in IAM Identity Center define access levels and are reusable across accounts.
Federation requires an IAM role with a trust policy that references the identity provider.
IAM Identity Center can use its own identity store or connect to external IdPs like Okta, Azure AD.
Federation is free; you pay only for AWS resources accessed.
The exam expects you to recognize when to use federation vs. IAM users vs. Cognito.
Common wrong answer: federation creates IAM users (it does not).
These come up on the exam all the time. Here's how to tell them apart.
SAML 2.0 Federation
Uses XML-based SAML assertions
Commonly used with enterprise IdPs like ADFS, Okta
Supports attribute-based access control via SAML attributes
Requires metadata exchange (XML document)
Token format is SAML assertion
OIDC Federation
Uses JSON Web Tokens (JWT)
Commonly used with social IdPs like Google, Facebook, and modern apps
Supports claims-based access control via JWT claims
Uses OAuth 2.0 flows; simpler configuration
Token format is JWT
IAM Users
Long-term credentials (access keys, password)
Managed within AWS IAM
Requires manual creation and deletion
Best for service accounts or small teams
Credentials can be rotated but not automatically expired
Federated Users
Temporary credentials from STS
Identities managed externally (IdP)
Automatic lifecycle management via IdP
Best for large number of users or employees
Credentials automatically expire; no long-term secrets
Mistake
Federation creates IAM users in the AWS account.
Correct
No. Federation does not create any IAM users. Users authenticate externally, and AWS issues temporary credentials via STS based on an IAM role trust policy.
Mistake
IAM Identity Center requires an external identity provider like Okta.
Correct
IAM Identity Center has its own built-in identity store, so you can use it without any external IdP. However, you can also connect external IdPs.
Mistake
SAML 2.0 and OIDC are interchangeable and work the same way.
Correct
They are different protocols. SAML uses XML assertions; OIDC uses JSON tokens. SAML is older, enterprise-focused; OIDC is modern, used for web and mobile apps. AWS supports both.
Mistake
Federation is only for accessing the AWS Management Console.
Correct
Federation works for console, CLI, and SDKs. Users can get temporary credentials for programmatic access as well.
Mistake
You can use federation without configuring any IAM roles.
Correct
You must create an IAM role with a trust policy that allows the identity provider to assume it. The role defines the permissions for federated users.
Federation is the underlying mechanism that allows identity information to be shared across trust boundaries. SSO is a user experience where a single login gives access to multiple systems. In AWS, federation enables SSO. For example, IAM Identity Center provides SSO by using federation (SAML/OIDC) to allow one login to access multiple AWS accounts and applications.
No. Federated users do not have IAM users. They authenticate externally and assume an IAM role via STS. The role provides temporary credentials. There is no IAM user object created for them.
Yes. Federated users can obtain temporary credentials for CLI/SDK by calling STS APIs (AssumeRoleWithSAML or AssumeRoleWithWebIdentity). IAM Identity Center provides a way to download temporary credentials from the portal. The credentials have an expiration and must be refreshed.
A permission set is a collection of IAM policies that define the level of access a user or group has in an AWS account. It is similar to an IAM role but managed centrally. You create permission sets with predefined or custom policies and assign them to users/groups for specific accounts.
Yes. IAM Identity Center has its own built-in identity store where you can create users and groups directly. This is useful for small organizations that don't have an existing IdP. However, for larger enterprises, connecting to an external IdP is recommended.
The temporary credentials become invalid. The user must re-authenticate with the IdP and obtain new credentials. In the console, they are redirected to the IdP login page. For programmatic access, the application must handle credential refresh by calling STS again.
Federation works for any service that can be accessed via the AWS API or Console. Since temporary credentials are used, there are no service-specific limitations. However, some services may have additional requirements (e.g., S3 bucket policies that check the `aws:userId` condition).
You've just covered AWS Identity Federation and SSO — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?