Continuous Discovery Enables Scalable IAM Identity Center Governance

AWS has released a sample solution that continuously discovers IAM Identity Center (formerly AWS Single Sign‑On) application assignments across an organization and outputs the data in a queryable store and CSV files. Practitioners need this because as the number of accounts, regions, and managed applications grows, manual tracking of who can access which application becomes error‑prone and hampers audit readiness.

Planning Governance for Identity Center Assignments

Four focus areas should be addressed before automating discovery:

1. Provisioning authority: Define which identities can create new managed applications. Existing mechanisms such as service control policies (SCP), resource control policies (RCP), or IaC policy tools like Open Policy Agent (OPA) and Checkov can be used to restrict provisioning to approved roles.
2. Assignment ownership: Separate the workflow that provisions resources from the workflow that manages user and group membership for each application. An IaC pipeline can handle the former, while a distinct request‑approval process can govern the latter.
3. Authentication flow: Users authenticate to Identity Center, receive access to a managed application, and then inherit downstream permissions. Understanding this chain is essential when mapping audit data to actual resource access.
4. Identity mapping: Establish a clear link between external IdP identities, Identity Center groups, managed applications, and any downstream IAM principals. Trusted identity propagation (TIP) provides an end‑to‑end trail for this mapping.

Architecture of the Continuous Discovery Solution

The sample solution performs the following steps:

1. Iterates over every AWS Organization unit and region to call Identity Center APIs that list managed applications and their assigned users and groups.
2. Normalizes the results into a structured format (e.g., JSON) that can be queried with standard tools.
3. Exports the normalized data to CSV files for downstream analysis, reporting, or ingestion into compliance dashboards.

Implementers must provision a role with read‑only permissions on Identity Center across the organization, schedule the discovery job (e.g., via EventBridge or a CI/CD pipeline), and secure the output storage (S3 bucket with encryption and least‑privilege access).

Operational and Security Considerations

Running the discovery process introduces several operational concerns:

• Frequency vs. cost: More frequent runs provide fresher data but increase API call volume and Lambda execution time.
• Cross‑region consistency: Ensure the discovery job runs in each region where Identity Center is enabled; missing a region creates blind spots.
• Data protection: The generated CSVs contain sensitive assignment information. Apply bucket policies, server‑side encryption, and audit logging to protect the data.
• Least‑privilege role design: The discovery role should only have identitystore:ListUsers, identitystore:ListGroups, and sso:ListApplications permissions needed for the queries.

From a security perspective, the solution helps answer questions such as “who last accessed a specific application?” and “which groups have access to which applications?” but it does not replace runtime enforcement. Practitioners should still enforce provisioning restrictions via SCP/RCP and IaC policy checks.

Related CloudNinjas coverage: AWS.

What This Means For Practitioners

Adopting the continuous discovery pattern gives teams a repeatable, auditable view of Identity Center assignments, reducing manual effort and supporting compliance checks. The next steps are to integrate the output into existing security dashboards, evaluate TIP for end‑to‑end traceability, and refine the provisioning policies that govern who can create or modify managed applications.