IAM Identity Center, External IdPs, and Workforce Federation

Why workforce identity is a SAP-C02 design problem

Task 1.2 on the AWS Certified Solutions Architect - Professional exam (SAP-C02) is not asking you to remember the Create user wizard. It is asking you to pick the identity plane that still works when a company has a Security OU, dozens of member accounts, an existing corporate directory, and auditors who need to know which human sat in which role. IAM Identity Center (renamed from AWS Single Sign-On on 26 July 2022; the sso and identitystore API namespaces remain for compatibility) is the AWS service for connecting workforce users to AWS accounts and to AWS managed applications such as Amazon Redshift and Amazon QuickSight. Independent OpenExamPrep teaching in this chapter follows that documented model: one federation point, short-term credentials, and centralized assignment. This guide is not an AWS publication and does not claim AWS approval, partnership, or exact equivalence with AWS training.

Long-lived IAM users in every member account fail that design. Passwords and access keys proliferate, joiner-mover-leaver processes miss accounts, and you cannot assign one Microsoft Entra ID group to eighty accounts without eighty copies of the same person. AWS IAM guidance is to require human users to federate through an identity provider rather than creating individual IAM users, except for a short list of cases such as emergency access when the IdP is down, a few third-party clients that cannot use Identity Center, and some CodeCommit or Amazon Keyspaces compatibility paths that still use service-specific credentials.

IAM Identity Center versus IAM users

Identity Center does not replace IAM. When a user picks a permission set in the AWS access portal, Identity Center still provisions or assumes an IAM role in the target account. You are choosing where humans live and how assignments are stored, not abandoning IAM policy evaluation.

Organization instances, account instances, and the Security OU

An organization instance of IAM Identity Center lives in the AWS Organizations management account. It is the only instance type that can manage access to AWS accounts with permission sets. AWS documents it as the production pattern. You can register a delegated administrator member account so staff in a Security OU operate Identity Center without using the management account as a daily console; the instance itself still resides in the management account. Delegated administration is covered with permissions boundaries in the third section of this chapter; the exam-critical fact here is that delegating administration does not move the instance out of the management account.

An account instance is bound to the AWS account in which you enable it. Use it only for isolated deployments of select AWS managed applications. It cannot run multi-account permission sets. If a scenario describes eighty workload accounts and a Security OU, an account instance in each workload account is the distractor.

When Identity Center is enabled, it can create a service-linked role in each account in the organization so it can provision access. Do not treat that role as a custom cross-account role you edit. The next section contrasts service-linked roles with custom roles.

Permission sets and the AWS access portal

A permission set is stored in IAM Identity Center and defines the level of access users and groups have to an AWS account. You need an organization instance to use them. You can start from a predefined AWS managed job-function policy (for example AdministratorAccess) and later tighten to customer managed policies, inline policies, and a permissions boundary referenced by the permission set. Assigning a permission set to a principal in an account provisions a corresponding IAM role in that account. Each assigned permission set appears as a role in the AWS access portal. AWS's documented least-privilege habit is to pick the most restrictive assigned set that still completes the task, not to park on AdministratorAccess because it is listed.

Session clocks are a professional-level detail, not trivia:

• AWS account session duration on a permission set defaults to one hour and can be set up to 12 hours. When it expires, the user is signed out of that console or CLI session and must obtain a new role session.
• AWS access portal session duration defaults to eight hours and can be configured up to 90 days. That clock is how long the worker stays signed into the portal before re-authenticating to the IdP.

Identity Center can also assign existing IAM roles in member accounts to Identity Center users and groups through account access manager. That path is useful when teams already built custom roles that differ by account and you still want centralized assignment. Permission sets remain the common job-function path.

Identity sources: one directory of record

You may have only one identity source per organization. The documented choices are:

1. Identity Center directory — default when you first enable the service; you create users and groups in AWS.
2. Active Directory — AWS Managed Microsoft AD or a connected on-premises AD. IAM Identity Center does not support SAMBA4-based Simple AD as an identity source.
3. External identity provider — for example Microsoft Entra ID or Okta, using SAML 2.0 for sign-in.

Changing the identity source is a destructive operational event: users and assignments from the previous source do not simply remap. Design the source before you scale assignments. If Active Directory will be the source and you use delegated administration, AWS's Identity Center guide places that directory in the delegated administrator member account, not in a random sandbox and not casually in the management account if you want the delegated admin to complete the setup.

SAML 2.0, OIDC, and SCIM

IAM Identity Center implements SAML 2.0 for workforce authentication to the access portal and System for Cross-domain Identity Management (SCIM) 2.0 for automatic provisioning of users and groups from an external IdP. AWS documents that Identity Center requires a SAML NameID format of email address (urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress) and an RFC 2822 addr-spec (name@domain.com) in that field. You typically manage one SAML signing certificate at the Identity Center application instead of one certificate per member account. That is the operational reason Identity Center exists at organization scale: federate once.

OpenID Connect (OIDC) still appears on SAP-C02, but usually in a different box. Identity Center's workforce IdP integration is SAML 2.0 plus SCIM. IAM OIDC identity providers in an account, together with AssumeRoleWithWebIdentity, are how workloads such as GitHub Actions obtain temporary credentials. Identity Center also exposes OIDC token endpoints so the AWS CLI and SDKs can obtain permission-set credentials after the human signs in (sso-oidc). Do not mash those three OIDC uses into "use Amazon Cognito for everyone."

SCIM is what stops you from hand-creating thousands of users in the Identity Center directory. The IdP is the source of truth for attributes and group membership. SCIM bearer tokens are high-value secrets. Delegated-admin guidance warns you to restrict who can create them so a member-account administrator cannot rewrite group membership outside the IdP. Write operations against the Identity Store APIs from a delegated admin account can also be overwritten on the next SCIM sync; treat the corporate directory as authoritative.

ABAC versus RBAC at organization scale

Role-based access control (RBAC) maps job functions to permission sets: Billing, SecurityAudit, PlatformAdmin, AppDeveloper. That is the right first cut. It explodes when every product team wants a unique permission set for every account (TeamA-Dev, TeamA-Test, TeamB-Dev, and so on).

Attribute-based access control (ABAC) uses attributes (in AWS, tags) so many people share one permission set, and the permission set's policies allow actions only when keys such as aws:PrincipalTag match aws:ResourceTag. IAM Identity Center can pass employee attributes from any configured identity source into the AWS session. AWS's Identity Center ABAC guide lists the operational benefits: fewer permission sets, automatic access to newly tagged resources, reuse of directory attributes, and CloudTrail sessions that carry those attributes so you can see which human attributes were in the session.

ABAC is not a substitute for tagging discipline. If developers can create untagged buckets, ABAC denies them; if they can retag production resources, they steal access. Pair ABAC with organization guardrails that restrict who can set Environment and Project tags. The governance chapter covers service control policies; this chapter's point is that Identity Center attributes only help if resource tags are trustworthy.

When Amazon Cognito is the wrong workforce answer

Amazon Cognito user pools add sign-up, sign-in, and tokens to your mobile or web application. Cognito identity pools exchange those tokens (or social, OIDC, or SAML IdP tokens) for IAM role credentials with AssumeRoleWithWebIdentity. That is customer identity and access management. It is the right design when shoppers, patients, or game clients call Amazon S3 or AWS AppSync. It is the wrong design when thousands of employees need the AWS Management Console, AWS CLI, and permission sets across a Security OU and workload OUs.

Cognito does not assign permission sets through AWS Organizations. It does not give you one SCIM pipeline from Entra ID into every member account. Putting each employee in a Cognito user pool because "it supports SAML" is an Associate-level trap on a Professional item. Use Cognito for the application's users. Use IAM Identity Center for the company's users who operate AWS.

Enterprise scenario: Northwind multi-account Security OU

Northwind Health runs AWS Organizations with a management account, a Security OU (Log Archive, Security Tooling, Identity), and workload OUs (Prod, NonProd). Employees already live in Microsoft Entra ID. The professional design is:

1. Enable an organization instance of IAM Identity Center in the management account.
2. Register the Security Tooling account as the Identity Center delegated administrator so identity engineers do not use the management account as a daily console.
3. Set the identity source to Entra ID (SAML 2.0) and enable SCIM so groups such as aws-platform-admins and aws-app-developers flow in.
4. Create a small set of permission sets (ReadOnly, a bounded PowerUser, SecurityAudit, a tightly scoped ProdDeploy). Use ABAC on Project and Environment tags so application developers share one permission set across NonProd accounts.
5. Assign users, not groups, to any permission set that can touch the management account. AWS documents that anyone who can change IdP group membership could otherwise add themselves to management-account access.
6. Keep a handful of break-glass IAM users with MFA in a physically controlled process for the day Entra ID is unavailable. They are not the 3,000-person access path.

Exam traps: treating Cognito as workforce SSO; creating IAM users in every account "for audit"; using account instances for org-wide SSO; treating permission sets as if they were SCPs; assuming Identity Center removes the need for IAM roles; using per-account OIDC IAM providers as the workforce directory; changing the identity source without planning assignment loss.