This chapter covers AWS IAM Identity Center (formerly AWS SSO) and SAML federation, critical topics for the Secure Architectures domain of the SAA-C03 exam. You will learn how to centrally manage user access to multiple AWS accounts and applications, and how to integrate with external identity providers using SAML 2.0. Expect 3-5 exam questions that test your understanding of federation concepts, IAM Identity Center configuration, and the differences between IAM roles, SAML federation, and IAM Identity Center.
Jump to a section
Imagine a large corporation with multiple buildings (AWS accounts) and a central HR office (IAM Identity Center). Each employee gets a single ID badge (federated user identity) issued by HR. When an employee wants to enter a building, they swipe their badge at the entrance (AWS access portal). The badge reader sends the badge ID to HR's authentication server, which verifies the employee's identity and checks a central database of access permissions (permission sets) that HR manages. HR then issues a temporary visitor pass (temporary AWS credentials) for that specific building, valid for a set time (session duration). The employee can enter the building and move around only as allowed by the pass. If the employee is fired, HR deactivates the badge in the central system, and all building access is instantly revoked across all buildings. Without this system, each building would need its own badge system, employees would carry multiple badges (multiple IAM users), and revoking access would require updating each building separately. The central HR office provides a single point of authentication and authorization, just as IAM Identity Center provides a single point of federation for multiple AWS accounts and business applications.
What is IAM Identity Center and Why Does It Exist?
AWS IAM Identity Center (successor to AWS Single Sign-On) is a cloud-based identity and access management service that enables you to centrally manage user access to multiple AWS accounts and business applications. It provides a single place to create or connect user identities, define granular permissions, and enable single sign-on (SSO) to AWS accounts, AWS applications (like Amazon Quicksight, Amazon S3), and third-party SaaS applications (like Salesforce, Office 365).
Before IAM Identity Center, managing access to multiple AWS accounts required creating IAM users in each account or using cross-account roles via IAM, which became unwieldy at scale. IAM Identity Center solves this by acting as a central identity source and authorization engine, reducing administrative overhead and improving security through centralized governance.
How It Works Internally: The Mechanism
IAM Identity Center works by integrating with an identity source (either its built-in identity store, or an external IdP via SAML 2.0 or SCIM) and mapping users and groups to AWS accounts and applications via permission sets.
Identity Source: IAM Identity Center stores user and group identities in a directory. By default, it uses its own identity store. Alternatively, you can connect to an external IdP such as Azure AD, Okta, or any SAML 2.0-compatible IdP. The IdP authenticates the user and sends a SAML assertion to IAM Identity Center.
Permission Sets: A permission set is a collection of IAM policies (AWS managed or customer managed) that defines the level of access a user or group has to an AWS account. Permission sets are created in the IAM Identity Center console and can include inline policies and managed policies. When a user requests access to an account, IAM Identity Center creates a temporary IAM role in the target account that the user can assume.
AWS Access Portal: Users access a unique URL (e.g., https://d-1234567890.awsapps.com/start) to log in. The portal displays the AWS accounts and applications the user has permission to access. After authentication, the user can click an account to get a set of temporary credentials (AWS access key, secret key, session token) that are valid for a configurable session duration (default 60 minutes, up to 12 hours for AWS accounts).
Temporary Credentials: IAM Identity Center uses AWS Security Token Service (STS) to generate temporary credentials. The permission set defines the permissions for the role created in the target account. The role's trust policy allows the IAM Identity Center service principal to assume the role. When a user selects an account, IAM Identity Center assumes the role on behalf of the user and returns the temporary credentials to the user's browser or AWS CLI.
Key Components, Values, Defaults, and Timers
Identity Center Instance: Each AWS organization can have one IAM Identity Center instance. It is enabled at the management account level.
Session Duration: Default 60 minutes for AWS account access, configurable from 15 minutes to 12 hours. Application sessions have a separate duration (default 1 hour for custom SAML 2.0 apps).
Permission Set: Maximum 1000 permission sets per AWS account. Each permission set can have up to 10 managed policies and one inline policy.
Groups and Users: IAM Identity Center supports up to 50,000 users per instance. Groups can have up to 10,000 members.
SCIM: System for Cross-domain Identity Management (SCIM) v2.0 can be used to automatically sync users and groups from an external IdP to IAM Identity Center.
SAML 2.0: IAM Identity Center supports SAML 2.0 for both identity federation (connecting an external IdP) and application federation (providing SSO to SAML-enabled apps).
Configuration and Verification Commands
To configure IAM Identity Center via AWS CLI, you use the sso-admin and identitystore commands. For example:
# Create a permission set
aws sso-admin create-permission-set --name ReadOnlyAccess --instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef0 --session-duration PT2H
# Attach a managed policy to the permission set
aws sso-admin attach-managed-policy-to-permission-set --instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef0 --permission-set-arn arn:aws:sso:::permissionSet/ssoins-1234567890abcdef0/ps-1234567890abcdef0 --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
# Assign a user or group to an AWS account with the permission set
aws sso-admin create-account-assignment --instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef0 --target-id 123456789012 --target-type AWS_ACCOUNT --permission-set-arn arn:aws:sso:::permissionSet/ssoins-1234567890abcdef0/ps-1234567890abcdef0 --principal-type USER --principal-id u-1234567890abcdef0To verify the configuration, use:
# List permission sets
aws sso-admin list-permission-sets --instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef0
# List account assignments for a permission set
aws sso-admin list-account-assignments --instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef0 --account-id 123456789012 --permission-set-arn arn:aws:sso:::permissionSet/ssoins-1234567890abcdef0/ps-1234567890abcdef0How It Interacts with Related Technologies
AWS Organizations: IAM Identity Center requires AWS Organizations to be enabled in the management account. It automatically discovers all accounts in the organization and can assign permissions to any account.
IAM Roles: In the target account, IAM Identity Center creates an IAM role with a trust policy that allows the service to assume it. The role name is AWSReservedSSO_<permission-set-name>_<random-string>. These roles should not be modified manually.
AWS CloudTrail: All IAM Identity Center activities (user assignments, login events, permission set changes) are logged in CloudTrail.
AWS Managed Policies: Permission sets can use AWS managed policies like ReadOnlyAccess, AdministratorAccess, or custom policies.
SAML Federation (Standalone)
SAML federation is a separate concept from IAM Identity Center. It allows users authenticated by an external IdP to assume an IAM role in a single AWS account. The trust relationship is defined in the IAM role's trust policy. The user receives temporary credentials via STS. This is useful when you need to federate access to a single account without using IAM Identity Center.
How SAML Federation Works:
1. User authenticates to external IdP (e.g., Okta).
2. IdP generates a SAML assertion containing user attributes (e.g., email, groups).
3. User's application (e.g., AWS Management Console) sends the assertion to AWS STS AssumeRoleWithSAML API.
4. STS validates the assertion and returns temporary credentials scoped to the IAM role specified in the assertion.
5. User can now access AWS resources using those credentials.
Key Components:
- SAML 2.0 Assertion: Contains authentication and authorization data, signed by the IdP.
- IAM Role: Trust policy allows the IdP (by its ARN) and specifies conditions (e.g., saml:sub).
- STS Endpoint: https://sts.amazonaws.com (global) or regional endpoints.
Default Values:
SAML assertion validity: Typically 1 hour (IdP dependent).
STS temporary credentials duration: Minimum 15 minutes, maximum 1 hour (default 1 hour).
Verification:
# Assume role with SAML (example using curl)
aws sts assume-role-with-saml --role-arn arn:aws:iam::123456789012:role/SAML-Admin --principal-arn arn:aws:iam::123456789012:saml-provider/Okta --saml-assertion base64-encoded-assertionComparison with IAM Identity Center
Scope: SAML federation works per AWS account; IAM Identity Center works across multiple accounts in an organization.
User Management: SAML federation requires the IdP to manage users; IAM Identity Center can use its own identity store or sync from IdP.
Permission Management: SAML federation uses IAM roles with trust policies; IAM Identity Center uses permission sets that are easier to manage at scale.
SSO: IAM Identity Center provides a built-in portal for SSO to multiple accounts and apps; SAML federation typically requires a custom portal or direct IdP integration.
Exam-Relevant Details
IAM Identity Center is the preferred method for managing access to multiple AWS accounts.
SAML federation is still used for single-account federation or when integrating with IdPs that don't support SCIM.
IAM Identity Center can be configured with an external IdP for authentication while using its own permission sets for authorization.
Session duration for AWS accounts is configurable but cannot exceed 12 hours.
Permission sets can include both AWS managed and customer managed policies.
IAM Identity Center supports attribute-based access control (ABAC) using user attributes passed from the IdP.
The AWSReservedSSO_* roles are automatically created and should not be deleted or modified.
Enable AWS Organizations
IAM Identity Center requires AWS Organizations to be enabled in your management account. If you already have an organization, you can proceed. If not, create one. The management account becomes the delegated administrator for IAM Identity Center. This step is irreversible once IAM Identity Center is enabled. Verify by checking that the organization is active and all member accounts are in the 'ACTIVE' state.
Enable IAM Identity Center
Navigate to the IAM Identity Center console in the management account. Click 'Enable'. This creates an IAM Identity Center instance with a unique ARN. The instance is tied to the organization. During enablement, you choose the identity source: either the built-in identity store or an external IdP. The default is the built-in store. After enablement, you get an AWS access portal URL (e.g., https://d-1234567890.awsapps.com/start).
Choose Identity Source
You can use the default IAM Identity Center identity store, or connect an external IdP via SAML 2.0. If using an external IdP, you must provide the IdP's SAML metadata document. Optionally, enable SCIM to automatically sync users and groups from the IdP. SCIM requires an access token generated by IAM Identity Center. The IdP pushes user and group updates to IAM Identity Center's SCIM endpoint.
Create Users and Groups
If using the built-in identity store, create users and groups manually via console, CLI, or API. Each user has attributes like username, email, first name, last name, and display name. Groups can contain users. If using an external IdP, users and groups are synced automatically (if SCIM is enabled) or created manually. Up to 50,000 users and 10,000 groups per instance.
Create Permission Sets
A permission set defines the level of access for an AWS account. Create one or more permission sets with the desired IAM policies. You can include AWS managed policies, customer managed policies, and inline policies. Set the session duration (default 1 hour). Permission sets are reusable across multiple accounts. Example: a 'ReadOnlyAccess' permission set with the AWS managed ReadOnlyAccess policy.
Assign Users/Groups to Accounts
Assign users or groups to specific AWS accounts with the appropriate permission set. This creates an account assignment. IAM Identity Center automatically creates an IAM role in the target account with a trust policy allowing the service to assume it. The role name follows the pattern `AWSReservedSSO_<permission-set-name>_<random-string>`. You can assign multiple permission sets to the same user/account combination.
User Accesses AWS Portal
Users receive the AWS access portal URL and log in using their credentials (authenticated by the identity source). The portal displays all AWS accounts and applications they have access to. When the user clicks an account, IAM Identity Center assumes the corresponding role and provides temporary credentials. The user can then access the AWS Management Console or use the AWS CLI with those credentials.
Scenario 1: Centralized Access for a Multi-Account Enterprise
A company with 50 AWS accounts and 2,000 employees uses IAM Identity Center to manage access. They connect their corporate Active Directory to IAM Identity Center via SAML 2.0 and SCIM. Users are grouped by department (e.g., Developers, Finance, Operations). Permission sets are created for common roles: 'DeveloperAccess', 'FinanceReadOnly', 'AdminAccess'. Assignments are made per group per account. The DevOps team can grant access to a new employee by adding them to the appropriate AD group, and SCIM syncs the change within minutes. Session duration is set to 4 hours for developers and 1 hour for finance. The company uses CloudTrail to audit all SSO events. A common issue is that users forget to log out of the portal, and their session expires, requiring re-authentication. To mitigate, they set session duration appropriately and educate users.
Scenario 2: SAML Federation for a Single Account
A startup uses a third-party IdP (Okta) to provide access to a single AWS account. They create an IAM role in the account with a trust policy that allows the Okta SAML provider to assume the role. The trust policy uses a condition to restrict access based on the user's group membership in Okta. Users authenticate via Okta's dashboard and click an AWS app tile, which generates a SAML assertion and sends it to AWS STS. The startup uses this setup because they have only one account and want to avoid the overhead of IAM Identity Center. A common mistake is misconfiguring the SAML assertion's Role attribute, causing STS to reject the request. They use CloudWatch metrics to monitor AssumeRoleWithSAML failures.
Scenario 3: Application SSO with IAM Identity Center
A mid-size company uses IAM Identity Center to provide SSO to both AWS accounts and SaaS applications like Salesforce and Office 365. They configure IAM Identity Center as a SAML identity provider for these apps. Users log in once via the AWS access portal and can access all assigned applications without re-authentication. The company uses SCIM to sync users from their HR system to IAM Identity Center, ensuring that when an employee leaves, their access is revoked automatically. Performance is not an issue as IAM Identity Center handles thousands of concurrent sessions. A common problem is that the SAML metadata for an application changes (e.g., after an update), breaking the SSO integration. They resolve this by updating the metadata in IAM Identity Center.
What SAA-C03 Tests
Objective 1.1: Design secure access to AWS resources. Specifically, you must know how to implement federation using IAM Identity Center and SAML 2.0.
Common Question Types: (1) Which service should you use to provide SSO to multiple AWS accounts? (2) How to integrate an external IdP with AWS? (3) What is the difference between IAM Identity Center and SAML federation? (4) How to set session duration for federated users? (5) Troubleshooting federation issues.
Common Wrong Answers
Choosing IAM users over federation: Candidates often think creating IAM users in each account is simpler. The exam expects you to recognize that federation is more secure and scalable, especially for large organizations.
Confusing IAM Identity Center with AWS Organizations: Some think AWS Organizations provides SSO. It does not – it only manages accounts and policies. IAM Identity Center is the SSO service.
Using IAM roles directly without federation: While you can create IAM roles for cross-account access, this does not provide SSO or centralized user management. The exam will test when to use IAM Identity Center vs. IAM roles.
Assuming SAML federation is the same as IAM Identity Center: SAML federation works per account and requires manual role configuration. IAM Identity Center abstracts this and works across accounts.
Specific Numbers and Terms
Session duration default: 60 minutes for AWS accounts.
Maximum session duration for AWS accounts: 12 hours.
Permission set limits: 1000 per account, 10 managed policies per set.
SCIM protocol version: v2.0.
IAM Identity Center instance limit: 1 per AWS organization.
STS endpoint for SAML: AssumeRoleWithSAML.
Role naming pattern: AWSReservedSSO_<permission-set-name>_<random-string>.
Edge Cases
What if you need to use an external IdP but also want to manage some users within IAM Identity Center? Not possible – you must choose one identity source. However, you can use the external IdP for authentication and then use IAM Identity Center's permission sets for authorization.
What if a user is assigned to multiple permission sets in the same account? The user can choose which role to assume from the access portal.
What if you delete a permission set? Existing sessions are not affected, but new sessions cannot be created. The IAM roles in accounts are not automatically deleted (you must clean them up).
How to Eliminate Wrong Answers
If the question mentions 'centralized access to multiple AWS accounts' and 'SSO', the answer is IAM Identity Center.
If the question involves a single account and an external IdP, the answer is SAML federation (IAM role with SAML provider).
If the question mentions 'attribute-based access control' or 'ABAC', look for IAM Identity Center with external IdP attributes.
If the question asks about 'session duration for federated users', remember the default 1 hour and max 12 hours for IAM Identity Center, and 1 hour for SAML federation via STS.
IAM Identity Center provides SSO to multiple AWS accounts and applications from a central location.
It requires AWS Organizations and is enabled in the management account.
Permission sets define access and are reusable across accounts.
Session duration for AWS accounts defaults to 60 minutes, max 12 hours.
SAML federation is used for single-account federation with an external IdP.
SCIM protocol v2.0 can sync users/groups from an external IdP to IAM Identity Center.
IAM Identity Center creates IAM roles named AWSReservedSSO_* in target accounts – do not modify.
The exam tests the difference between IAM Identity Center and SAML federation scenarios.
Attribute-based access control (ABAC) is supported via user attributes from the IdP.
CloudTrail logs all IAM Identity Center and SAML federation activities.
These come up on the exam all the time. Here's how to tell them apart.
IAM Identity Center
Centralized SSO for multiple AWS accounts and applications.
Uses permission sets to define access across accounts.
Built-in identity store or external IdP via SAML/SCIM.
Session duration configurable up to 12 hours.
Automatic IAM role creation in target accounts.
SAML Federation (Standalone)
Federates access to a single AWS account per IAM role.
Requires manual IAM role and trust policy configuration.
Relies entirely on external IdP for user management.
Session duration max 1 hour (via STS).
No automatic role creation; roles must be pre-configured.
Mistake
IAM Identity Center requires an external identity provider.
Correct
IAM Identity Center has its own built-in identity store, so you can use it without any external IdP. You can create users and groups directly in IAM Identity Center.
Mistake
SAML federation and IAM Identity Center are the same thing.
Correct
They are different. SAML federation is a protocol used to exchange authentication data; it can be used standalone to access a single AWS account. IAM Identity Center is a service that provides SSO to multiple accounts and applications, and it can use SAML as one method to connect an external IdP.
Mistake
You can use IAM Identity Center without AWS Organizations.
Correct
IAM Identity Center requires AWS Organizations. You must have an organization enabled in your management account to use IAM Identity Center.
Mistake
IAM Identity Center creates IAM users in each account.
Correct
No, IAM Identity Center creates IAM roles (not users) in each account. The roles are assumed by users authenticated through the IAM Identity Center portal.
Mistake
You can modify the IAM roles created by IAM Identity Center.
Correct
You should not modify the `AWSReservedSSO_*` roles manually. Doing so may break access. IAM Identity Center manages these roles automatically.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
IAM Identity Center is a service for centrally managing access to multiple AWS accounts and applications using SSO. IAM is the core AWS service for managing users, groups, roles, and policies within a single account. IAM Identity Center uses IAM roles (created automatically) to grant access to accounts, but it does not create IAM users. The exam tests when to use each: use IAM for fine-grained access within one account; use IAM Identity Center for multi-account SSO.
Yes, IAM Identity Center has its own built-in identity store. You can create users and groups directly in IAM Identity Center without connecting an external IdP. This is useful for smaller organizations or testing. However, for production, you may want to connect to an existing directory (like Active Directory) using SAML 2.0 or SCIM.
Session duration is set at the permission set level. When creating or editing a permission set, you can specify a duration from 15 minutes to 12 hours. The default is 60 minutes. This duration applies to AWS account access. Application sessions have a separate duration (default 1 hour for custom SAML 2.0 apps).
Deleting a permission set does not immediately revoke existing sessions; those sessions remain active until they expire. However, new sessions cannot be created using that permission set. The IAM roles (AWSReservedSSO_*) created in target accounts are not automatically deleted – you must clean them up manually if needed. Assignments that used the deleted permission set become invalid.
Yes, IAM Identity Center supports SSO to thousands of pre-integrated SaaS applications (like Salesforce, Office 365, Slack) and custom SAML 2.0 applications. You configure the application in IAM Identity Center and assign users/groups. Users then access these applications from the AWS access portal without needing separate credentials.
SCIM (System for Cross-domain Identity Management) is used to automatically synchronize users and groups from an external identity provider (like Azure AD, Okta) to IAM Identity Center. This eliminates the need to manually create users in IAM Identity Center. The IdP pushes changes (new users, group membership updates) to IAM Identity Center's SCIM endpoint.
SAML federation allows users authenticated by an external IdP to assume an IAM role in a single AWS account. The IdP generates a SAML assertion containing user attributes and sends it to AWS STS via the `AssumeRoleWithSAML` API. STS validates the assertion and returns temporary credentials. The IAM role must have a trust policy that allows the SAML provider to assume it.
You've just covered AWS IAM Identity Center (SSO) and SAML Federation — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?