This chapter covers AWS IAM Identity Center (formerly AWS SSO), a core service for centrally managing access to multiple AWS accounts and cloud applications. For the SOA-C02 exam, this topic falls under Domain 4: Security, Objective 4.1 (Implement and manage security and compliance controls). Approximately 5-8% of exam questions touch on IAM Identity Center, often in scenarios involving multi-account management, federation with external identity providers, and permission set configuration. Mastering this chapter will equip you to answer questions about user provisioning, single sign-on workflows, and troubleshooting access issues.
Jump to a section
Imagine a large corporation with multiple offices (AWS accounts), each with its own security guard (IAM). Employees need to access different offices for different projects. Instead of issuing separate ID cards for every office, the company implements a centralized badge system: an identity store (like AWS IAM Identity Center) that holds every employee's digital identity. When an employee wants to enter Office A, they scan their badge at the door. The badge reader sends the badge ID to the central authentication server, which verifies the employee's identity and checks a policy that says 'Employee John can access Office A between 9 AM and 5 PM on weekdays.' The server then issues a temporary access token (like a SAML assertion or session token) that the employee presents to Office A's security guard. The guard validates the token against the central server's public key and grants entry. Importantly, the guard never sees the employee's full identity store; they only trust the token. If John moves to a new role, the central admin updates his permissions in the identity store once, and all offices automatically honor the change. This is exactly how IAM Identity Center works: it centralizes user identities and permissions, issuing temporary credentials that AWS accounts and applications trust via SAML 2.0 or OIDC. The identity store can be the built-in directory or an external IdP like Okta or Azure AD, and the policies are permission sets that map to IAM roles. The temporary credentials are short-lived (default 1 hour for console sessions, up to 12 hours for programmatic access), ensuring that even if a token is stolen, its window of misuse is limited.
What is AWS IAM Identity Center?
AWS IAM Identity Center (formerly AWS Single Sign-On) is a cloud-based service that makes it straightforward to centrally manage access to multiple AWS accounts and business applications. It allows you to create or connect your workforce identities (users and groups) once and then grant them access to AWS resources across all your accounts in AWS Organizations. It also supports single sign-on (SSO) to popular SaaS applications like Salesforce, Office 365, and Box, as well as custom OIDC- or SAML 2.0-enabled applications.
Why it Exists
Prior to IAM Identity Center, administrators had to manually create IAM users in each AWS account, manage passwords, and rotate keys. For organizations with dozens or hundreds of accounts, this was unsustainable. IAM Identity Center solves this by providing a single place to define users and groups, assign permissions through permission sets (which map to IAM roles), and automatically provision those permissions across accounts. It also integrates with external identity providers (IdPs) via SAML 2.0 or SCIM, enabling federation and centralized user lifecycle management.
How It Works Internally
When a user signs in to the IAM Identity Center user portal (https://<your-identity-store>.awsapps.com/start), the following steps occur:
1. The user authenticates against the identity source (either the built-in IAM Identity Center directory or an external IdP). If using an external IdP, SAML 2.0 assertions are exchanged.
2. After successful authentication, the user sees a dashboard of AWS accounts and applications they have access to.
3. When the user clicks on an AWS account (e.g., 'Production'), IAM Identity Center generates a temporary security credential for that account by assuming an IAM role that corresponds to the permission set assigned to the user for that account.
4. The user is automatically signed in to the AWS Management Console as that role, without needing a separate IAM user in the target account.
5. For programmatic access (AWS CLI or SDK), the user can request temporary credentials via the IAM Identity Center credential provider (e.g., aws sso login command). The credentials are valid for a configurable session duration (1 to 12 hours for AWS access, default 1 hour).
Key Components, Values, Defaults, and Timers
Identity Source: Can be the IAM Identity Center built-in directory, an Active Directory (AWS Managed Microsoft AD or self-managed AD via AD Connector), or an external IdP (Okta, Azure AD, etc.). The default is the built-in directory.
Permission Sets: A collection of policies (AWS managed policies, customer managed policies, inline policies) that define the level of access. Permission sets are mapped to IAM roles in target accounts. A permission set can have a session duration (default 1 hour, configurable up to 12 hours).
AWS Organizations: IAM Identity Center must be enabled at the management account level. It can then manage access to all accounts in the organization.
SCIM (System for Cross-domain Identity Management): Used to automatically sync users and groups from an external IdP to IAM Identity Center. Default sync interval is every 40 minutes, but can be triggered manually.
SAML 2.0 Assertions: When using an external IdP, SAML assertions carry user attributes (like email, groups) to IAM Identity Center. The attribute mapping is configurable.
Session Duration: For console access, the session duration is set in the permission set (1-12 hours). For programmatic access, the AWS CLI defaults to 1 hour but can be extended via the --duration-seconds parameter in aws configure sso.
User Portal URL: The unique URL for your IAM Identity Center instance, typically https://<your-identity-store-id>.awsapps.com/start.
Configuration and Verification Commands
To configure IAM Identity Center using AWS CLI:
1. Enable IAM Identity Center: aws organizations enable-aws-service-access --service-principal sso.amazonaws.com (requires management account).
2. Create a permission set:
aws sso-admin create-permission-set --name ReadOnly --session-duration PT1H --instance-arn <instance-arn>Attach a managed policy to the permission set:
aws sso-admin attach-managed-policy-to-permission-set --permission-set-arn <ps-arn> --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess --instance-arn <instance-arn>Provision the permission set to an account:
aws sso-admin provision-permission-set --instance-arn <instance-arn> --permission-set-arn <ps-arn> --target-id <account-id> --target-type AWS_ACCOUNTAssign users/groups: This is typically done via the console or AWS CLI create-account-assignment command.
To verify:
List permission sets: aws sso-admin list-permission-sets --instance-arn <instance-arn>
List assignments: aws sso-admin list-account-assignments --account-id <account-id> --permission-set-arn <ps-arn> --instance-arn <instance-arn>
Test login: aws sso login --profile my-sso-profile then aws sts get-caller-identity.
How It Interacts with Related Technologies
AWS Organizations: IAM Identity Center relies on AWS Organizations to manage accounts and service-linked roles. It creates a service-linked role named AWSServiceRoleForSSO in each member account.
IAM Roles: Each permission set creates an IAM role in the target account with a trust policy that allows IAM Identity Center to assume it. The role name follows the pattern AWSReservedSSO_<permission-set-name>_<random-id>.
CloudTrail: All IAM Identity Center administrative actions (e.g., CreatePermissionSet, ProvisionPermissionSet) are logged in CloudTrail. User sign-in events are also logged.
AWS Directory Service: If using AD as the identity source, IAM Identity Center integrates with AWS Managed Microsoft AD or AD Connector.
AWS CLI v2: The AWS CLI v2 supports SSO natively via the sso profile configuration. Users can run aws configure sso to set up a profile that uses IAM Identity Center credentials.
Permission Set Policies and Session Duration
Permission sets can include AWS managed policies, customer managed policies, and inline policies. They cannot include resource-based policies or service control policies (SCPs). SCPs are applied at the organization level and can further restrict what the permission set allows. Session duration is set on the permission set and overrides any role session duration set in the trust policy. The default is 1 hour, but you can set it from 1 to 12 hours. For security, shorter sessions are recommended.
Attribute-Based Access Control (ABAC)
IAM Identity Center supports ABAC by allowing you to pass user attributes (like department or cost center) from the identity source to AWS via SAML or OIDC. You can then use condition keys like aws:PrincipalTag/department in policies to grant access based on those attributes. This is powerful for scaling permissions without creating multiple permission sets.
Multi-Account Permissions
You can assign a single permission set to multiple accounts, or assign multiple permission sets to a single user across different accounts. The IAM Identity Center dashboard shows the user which accounts and roles they can access. Assignments can be made to individual users or to groups, which simplifies management.
Identity Federation with External IdPs
When you connect an external IdP (like Okta or Azure AD), IAM Identity Center acts as a service provider (SP). The IdP is the identity provider (IdP). Users authenticate at the IdP, which sends a SAML assertion to IAM Identity Center. IAM Identity Center then issues temporary AWS credentials. SCIM is used to automatically provision and deprovision users and groups from the IdP to IAM Identity Center. This ensures that when a user leaves the company, their access is revoked automatically.
Defaults and Limits
Maximum number of permission sets per instance: 1000 (soft limit, can be increased).
Maximum number of groups per instance: 5000.
Maximum number of users per instance: 50,000 (if using built-in directory).
Maximum number of accounts per assignment: 2000 per permission set.
Session duration: 1-12 hours for AWS access; 1-24 hours for application access (depending on application).
SCIM sync interval: approximately every 40 minutes.
Monitoring and Auditing
Use CloudTrail to monitor all IAM Identity Center API calls. For user sign-in events, CloudTrail logs the SignIn event with details like the user, account, and permission set used. You can also enable AWS Config rules to detect non-compliant permission sets. IAM Access Analyzer can help identify unused permissions.
Troubleshooting
User cannot see accounts: Check if the user is assigned to the account and permission set. Verify that the user is in the correct group (if using group assignments).
Permission set not appearing: Ensure the permission set is provisioned to the account. Check CloudTrail for ProvisionPermissionSet events.
Federation failure: Verify SAML metadata exchange, attribute mapping, and that the IdP is reachable. Check CloudTrail for Federate events.
SCIM sync issues: Ensure the SCIM endpoint is correctly configured in the IdP and that the bearer token is valid. Check IAM Identity Center logs for sync errors.
Enable IAM Identity Center
To use IAM Identity Center, you must first enable it in the AWS Organizations management account. Navigate to the IAM Identity Center console and click 'Enable'. This creates a service-linked role (AWSServiceRoleForSSO) in the management account and sets up the identity store. If you haven't already, you must enable AWS Organizations. IAM Identity Center cannot be disabled once enabled; you can only delete the instance. The default identity source is the built-in IAM Identity Center directory, but you can change it later.
Choose Identity Source
In the Settings page, choose your identity source: the built-in directory, Active Directory (AWS Managed Microsoft AD or AD Connector), or an external IdP. If using external IdP, you must configure SAML 2.0 federation: upload the IdP's SAML metadata file, and configure attribute mapping (e.g., map the IdP's 'email' attribute to IAM Identity Center's 'email'). If using SCIM, you will get a SCIM endpoint URL and bearer token to configure in the IdP. This step determines how users authenticate and how their attributes are passed.
Create Users and Groups
If using the built-in directory, manually create users and groups in the IAM Identity Center console. If using an external IdP with SCIM, users and groups are automatically synced from the IdP. You can also manually add groups and assign users to them. Users can have attributes like email, display name, and custom attributes for ABAC. Groups are essential for scalable permission assignments—assign permissions to groups rather than individual users.
Create Permission Sets
Permission sets define the level of access. In the console, go to Permission sets and click 'Create permission set'. You can start from a job function policy (e.g., AdministratorAccess, ReadOnlyAccess) or create a custom permission set. Add AWS managed policies, customer managed policies, or inline policies. Set the session duration (default 1 hour, max 12 hours). Optionally, define a relay state URL (the page users land on after login). Permission sets are reusable across accounts.
Assign Users/Groups to Accounts
In the AWS accounts section, select an account and click 'Assign users or groups'. Choose the users/groups and the permission set(s) to assign. 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 `AWSReservedSSO_<permission-set-name>_<random-id>`. You can also assign through the Groups tab. Assignments can be removed later, which deletes the corresponding role from the account.
User Login and Access
Users access the IAM Identity Center user portal URL. They authenticate using their identity source credentials. After authentication, they see a dashboard of AWS accounts and applications. Clicking an account triggers IAM Identity Center to assume the IAM role associated with the permission set. The user is then redirected to the AWS Management Console with that role. For programmatic access, users configure AWS CLI with `aws configure sso` and then run `aws sso login`. The CLI obtains temporary credentials from the IAM Identity Center token service.
Enterprise Scenario 1: Multi-Account Governance
A large enterprise with 100+ AWS accounts uses IAM Identity Center to centralize access. They connect their corporate Active Directory via AD Connector as the identity source. They create permission sets like 'SecurityAudit' (with SecurityAudit policy), 'NetworkAdmin' (with custom inline policy for VPC management), and 'ReadOnly'. These are assigned to AD groups (e.g., 'AWS-SecurityTeam', 'AWS-NetworkTeam') across all accounts. When a new network engineer joins, the IT team adds them to the 'AWS-NetworkTeam' AD group. SCIM syncs the group membership to IAM Identity Center within 40 minutes. The engineer can now access all accounts with NetworkAdmin permissions. When they leave, removal from the AD group automatically revokes access. The challenge is managing session duration: the default 1 hour is too short for long-running support sessions, so they increase it to 4 hours but still enforce MFA via the IdP. Misconfiguration: if the AD Connector goes down, users cannot authenticate; they set up a redundant AD connector in another region.
Enterprise Scenario 2: SaaS Application SSO
A mid-size company uses Salesforce, Office 365, and Slack. They enable IAM Identity Center and configure it as a SAML 2.0 identity provider for these applications. Users log in once to the IAM Identity Center portal and can access all applications without re-entering credentials. The company uses the built-in IAM Identity Center directory. They create groups like 'SalesTeam' and assign access to Salesforce. When a salesperson is hired, they are added to the group and automatically get Salesforce access. The main issue is attribute mapping: if the email attribute in IAM Identity Center doesn't match the username format in Salesforce, authentication fails. They must ensure consistent attribute naming. Also, session duration for applications is separate from AWS; they set it to 8 hours to match the workday.
Enterprise Scenario 3: ABAC for Dynamic Permissions
A tech startup with rapidly changing teams uses ABAC to avoid updating permission sets. They configure IAM Identity Center to pass a custom attribute 'costCenter' from their Okta IdP. They create a permission set with a policy that grants access to S3 buckets tagged with the same costCenter. When a user moves to a new project, the Okta admin updates the costCenter attribute, and the policy automatically grants access to the new buckets. This eliminates the need to reassign permission sets. The challenge is ensuring the attribute is correctly mapped in the SAML assertion. They also use CloudTrail to audit attribute changes. Misconfiguration: if the attribute is missing, the user gets no access; they set a default value of 'none' and deny all actions for that tag.
What SOA-C02 Tests on IAM Identity Center
The exam focuses on Objective 4.1: Implement and manage security and compliance controls. Specific areas include:
Understanding the difference between IAM Identity Center and traditional IAM users/roles.
Configuring permission sets and assigning them to accounts.
Integrating with external IdPs via SAML 2.0 and SCIM.
Session duration settings and their impact on security.
ABAC and attribute mapping.
Troubleshooting access issues (e.g., user cannot see accounts).
Common Wrong Answers and Why Candidates Choose Them
'IAM Identity Center creates IAM users in each account' — This is wrong because IAM Identity Center uses IAM roles, not users. Candidates confuse it with traditional IAM user management. The correct answer is that it creates IAM roles with trust policies.
'Permission sets are SCPs' — Permission sets are not SCPs. SCPs are organization-level policies that restrict what IAM roles can do. Permission sets define the actual permissions granted to the role. Candidates often mix these up.
'You can use IAM Identity Center without AWS Organizations' — IAM Identity Center requires AWS Organizations. It cannot be used with standalone accounts. Candidates who are new to multi-account management might think it works with any account.
'Session duration can be set to any value' — The maximum is 12 hours for AWS access. Candidates might assume it can be longer, but the exam tests the 12-hour limit.
Specific Numbers and Values to Memorize
Session duration: 1 to 12 hours for AWS access (default 1 hour).
SCIM sync interval: approximately 40 minutes.
Maximum permission sets per instance: 1000 (soft).
Maximum users (built-in directory): 50,000.
Maximum groups per instance: 5000.
The role name pattern: AWSReservedSSO_<permission-set-name>_<random-id>.
The service-linked role: AWSServiceRoleForSSO.
Edge Cases and Exceptions
If you delete a permission set assignment, the IAM role is deleted from the target account. However, if the role is used by a running resource (e.g., an EC2 instance with an instance profile), the role cannot be deleted until the instance is stopped. The exam might test that you need to remove dependencies first.
When using an external IdP, the SAML assertion must include the RoleSessionName attribute; otherwise, the user will get an error.
IAM Identity Center does not support cross-account access for services that require long-term credentials (e.g., some third-party tools).
How to Eliminate Wrong Answers
If the question mentions 'federation with an external identity provider', look for answers that mention SAML 2.0 or OIDC. Avoid answers that say 'IAM users' or 'access keys'.
If the question is about granting access to multiple accounts, the answer should involve IAM Identity Center and permission sets, not IAM roles directly.
For session duration questions, remember the 12-hour limit. If an answer says '24 hours', it's wrong.
For troubleshooting, check if the user is assigned to the account and permission set. If the answer suggests checking IAM users, it's likely wrong.
IAM Identity Center centralizes access to multiple AWS accounts and applications using IAM roles, not IAM users.
Permission sets define the permissions and session duration (1-12 hours, default 1 hour).
Identity source can be built-in directory, Active Directory, or external IdP via SAML 2.0.
SCIM automatically syncs users and groups from external IdPs every ~40 minutes.
IAM Identity Center requires AWS Organizations; it cannot be used with standalone accounts.
The service creates a service-linked role named AWSServiceRoleForSSO.
ABAC allows using user attributes in policies for dynamic access control.
All actions are logged in CloudTrail for auditing.
These come up on the exam all the time. Here's how to tell them apart.
IAM Identity Center
Centralized user management across multiple AWS accounts.
Supports federation with external IdPs (SAML 2.0, OIDC).
Uses IAM roles with trust policies for access.
Session duration configurable per permission set (1-12 hours).
Automatic provisioning and deprovisioning via SCIM.
Traditional IAM Users/Roles
Users are created in each account individually.
Does not natively support federation (requires custom SAML setup).
Uses IAM users or roles directly.
Session duration set in role trust policy or user password policy.
Manual user creation and deletion per account.
Mistake
IAM Identity Center creates IAM users in each member account.
Correct
IAM Identity Center creates IAM roles in each account, not IAM users. The roles have trust policies that allow IAM Identity Center to assume them. Users authenticate centrally and assume these roles to access the account.
Mistake
Permission sets are the same as service control policies (SCPs).
Correct
Permission sets define the permissions granted to a role within an account. SCPs are organization-level policies that restrict what the role can do across accounts. They are complementary but different.
Mistake
You can use IAM Identity Center with standalone AWS accounts.
Correct
IAM Identity Center requires AWS Organizations. It cannot be enabled for a standalone account. You must have an organization with a management account.
Mistake
Session duration for AWS access can be set to any value up to 24 hours.
Correct
The maximum session duration for AWS access via IAM Identity Center is 12 hours. The default is 1 hour. Application access may have different limits.
Mistake
SCIM sync is instantaneous.
Correct
SCIM sync occurs approximately every 40 minutes. It is not real-time. If you need immediate provisioning, you can manually trigger a sync in the IAM Identity Center console.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
First, enable AWS Organizations if not already done. Then, in the management account, enable IAM Identity Center. Choose your identity source (built-in, AD, or external IdP). Create users and groups. Create permission sets that define the access level. Finally, assign users or groups to the target accounts with the desired permission set. Users will log in via the user portal URL and see the accounts they have access to.
A permission set is a template that defines a set of permissions (via policies) and session duration. When assigned to a user/group for an account, IAM Identity Center creates an IAM role in that account with the policies from the permission set. The role name follows the pattern AWSReservedSSO_<permission-set-name>_<random-id>. The permission set itself is not a role; it is a configuration that generates roles.
Yes. IAM Identity Center supports SAML 2.0 federation with external IdPs. You configure the IdP to send SAML assertions to IAM Identity Center. Additionally, you can enable SCIM to automatically sync users and groups from the IdP to IAM Identity Center. This allows centralized user lifecycle management.
This usually means the user is not assigned to any account. Check the assignments in IAM Identity Center: ensure the user (or their group) is assigned to the correct accounts with the appropriate permission set. Also verify that the user is authenticated correctly (if using external IdP, check SAML assertions). If the user is in a group, confirm the group is assigned.
Run `aws configure sso` and provide the SSO start URL (the user portal URL) and region. The CLI will open a browser for authentication. After successful login, it creates a profile with temporary credentials. You can then use `--profile <profile-name>` with any AWS CLI command. The credentials are cached and automatically refreshed when they expire.
The corresponding IAM role in the target account is deleted. Users will no longer be able to access that account via IAM Identity Center. However, if the role is referenced by a resource (e.g., an EC2 instance with an instance profile), the deletion will fail. You must remove such dependencies first.
Yes, by creating separate permission sets with different session durations and assigning them to different users or groups. Session duration is a property of the permission set, not the user. So you can have a 'Admin' permission set with a 1-hour session and a 'Support' permission set with a 4-hour session.
You've just covered AWS IAM Identity Center (SSO) — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?