You've deployed AWS IAM Identity Center, integrated your external identity provider, and assigned users to applications. Your team assumes the hard part is done. But three months later, you're fielding audit questions you can't answer quickly: Which groups have access to that SageMaker AI domain? Who provisioned this Identity Center application? When did that user last authenticate?
These gaps stem from persistent myths about how Identity Center governance actually works. Let's correct them.
Myth 1: IAM Policies Can Restrict Who Manages Specific Identity Center Applications
Reality: IAM Identity Center application ARNs use GUIDs generated at creation time, not the friendly resource names you assigned. When you create a SageMaker AI domain called "Data_Science_Prod," the resulting Identity Center application ARN looks like arn:aws:sso::123456789012:application/ssoins-abc123/apl-xyz789. You don't control that GUID, and you can't predict it.
This makes resource-level IAM restrictions impractical. To limit application assignment permissions to specific applications, you'd need to:
- Create the AWS resource with Identity Center authentication enabled.
- Query the Identity Center application ARN for that resource.
- Update the IAM policy for your authorized principals to include that specific ARN.
- Update your Service Control Policy to prevent other principals from managing it.
That's a reactive process for every new application. Instead, limit Identity Center application provisioning to a small number of authorized IAM principals and implement detective controls. Your governance model should assume you'll discover and report on assignments, not prevent them through resource-level IAM policies.
Myth 2: You Can Hide Sensitive Groups from Application Administrators
Reality: The identitystore:ListUsers and identitystore:ListGroups actions require the AllUsers or AllGroups parameter. You can't write a restrictive IAM policy that lets an application administrator see only the groups they're supposed to manage.
If your Identity Center instance contains a group called "AWS_Finance_SensitiveData_PROD," anyone with permission to list groups will see it. This matters when you delegate application assignment responsibilities. Your SageMaker administrator who needs to assign data scientists to domains will also see your finance groups, your security groups, and your executive access groups.
Your mitigation strategy: treat group visibility as a given and focus on assignment auditing. Implement continuous discovery to detect when unauthorized groups get assigned to applications. Don't rely on IAM policies to enforce "need to know" at the identity store level.
Myth 3: Naming Conventions Are Optional Documentation
Reality: Naming conventions become your only reliable mapping between IdP groups, Identity Center applications, and AWS resources when you're answering audit questions at scale.
Consider the relationship chain: your IdP group "AWS_123412341234_SageMaker_Data_PROD_GTLabel" maps to an Identity Center application (with a GUID you didn't choose) that authorizes access to a SageMaker AI domain called "SageMaker_Data_GTLabel." Without consistent naming across that chain, you're querying APIs and cross-referencing GUIDs manually during every access review.
Define your conventions before you scale:
- IdP groups:
AWS_<AccountID>_<Service>_<LOB>_<Environment>_<AppName> - AWS resources:
<Service>_<LOB>_<AppName> - Identity Center applications:
<Service>_<LOB>_<Environment>_<AppName>
When your naming convention embeds account ID, service, line of business, environment, and application name consistently, you can automate governance queries. When it doesn't, you're reading documentation and guessing.
Myth 4: Application Provisioning and Assignment Management Should Use the Same Workflow
Reality: These are distinct governance problems requiring different controls.
Application provisioning determines which AWS resources get created with Identity Center authentication enabled. This should be tightly controlled through infrastructure as code pipelines, with IAM policies, Service Control Policies, or Resource Control Policies enforcing who can create these integrations.
Application assignment management determines which users and groups can access those applications. This happens after provisioning and requires different permissions: sso:CreateApplicationAssignment, sso:DeleteApplicationAssignment, and sso:ListApplicationAssignments.
Conflating these workflows creates either overly permissive provisioning (application owners can create new integrations) or overly restrictive assignment (only central teams can grant access, creating bottlenecks). Separate them. Use IaC for provisioning, then implement a request workflow for assignments that authorized application administrators can execute.
Myth 5: Delegated Administration Means You've Decentralized Governance
Reality: Enabling delegated administration for Identity Center is a security practice, but it doesn't automatically distribute governance responsibilities effectively.
Delegated administration lets you manage Identity Center from a member account instead of your management account. That's important for reducing management account exposure. But it doesn't tell you which member accounts should provision applications, who should manage assignments within those accounts, or how you'll maintain visibility across your organization.
You still need to define: who provisions managed applications in each account, who manages user and group assignments for those applications, how authentication flows from your IdP to AWS resources, and how you map IdP identities to downstream resource access. Delegated administration is a deployment decision, not a governance framework.
What to Do Instead
Build governance around continuous discovery, not preventive controls. You need automated reporting that answers:
- Which users or groups have access to which AWS applications?
- Who last accessed a specific application and when?
- Which users and groups are assigned to Identity Center applications across accounts and Regions?
Store this data in a queryable format. Generate CSV exports for audit requests. When you can answer these questions in minutes instead of days, you've shifted from reactive firefighting to proactive governance.
Your IAM policies should limit who can provision applications and who can manage assignments. Your naming conventions should make relationships between IdP groups, applications, and resources machine-readable. Your reporting should run continuously, not when auditors ask. That's the difference between governing Identity Center and just using it.
AWS Identity and Access Management (IAM) AWS Service Control Policies
