Configurable handling of 'manually created' Users/Groups in IAM Identity Center

[ChrisPates]

Is your feature request related to a problem? Please describe.
Normal behavior for a uni-directional identity replication is that the downstream IdP, will contain only the user/groups (or a sub-set there of) that exist in the upstream IdP.

With IAM Identity Center, local users (those that do not exist in the upstream IdP) can exist but will not be able to authenticate (since the upstream SAML IdP can not create a auth token for a user identity it doesn't have).

AWS Control Tower's behavior of creating groups (at LZ setup time) and users (as part of account factory provisioning), also its assigning of Administrator Access. Is often found to be inconsistent with organizations Identity Management principles and the permissions granted excessive for the principle of least privilege. This behavior also only implemented when using the Identity Store with IAM Identity Center, where an instance of AWS Managed Microsoft AD or AWS Directory Service, these users are not created.

Describe the solution you'd like
Some users may wishes to handle locally created users and groups in a specific fashion (related issues: #141, #88, #59:

• delete (default and current behavior)
  • Groups are deleted
  • Users are deleted
• disable
  • Groups are ignored
  • Users are disabled
• ignore
  • Groups are ignored
  • Users are ignored

The above behavior should be configurable, via either cli parameter or environment variable (lambda)

Describe alternatives you've considered

• A list of Groups/User named to ignore
  • likely to differ between customer environments,
  • changes in service behavior (AWS Control Tower for example) may cause issues
• regex based
  • more configurable than above, but has many of the same limitations

Additional context
'Manual' as a creation method is an implicit property and can not be directly interrogated via the apis, for this reason it would be necessary to start using the externalId field (see related enhancement Ensure all groups/user creates in IAM Identity Store are via SCIM api and populate externalId field #166) to allow the code to determine what resources are SCIM provision but no longer exist upstream vs manually created resources that only exist in IAM Identity Center.

[CarlosCuevas]

As a bandaid, would it be possible to add a flag that works like ignore users and/or groups but specifically for deletion from aws?

[ChrisPates]

A better work around would be to create the control tower managed groups in the Google workspaces directory (match is currently on display name), so they are matched and preserved. The users are irrelevant as without a matching user on the google side they would never be able to authenticate. Chris

[CarlosCuevas]

I have a slightly different scenario in mind. The user already exists within Google but we temporarily modify their group memberships within AWS. It would be nice to be able to pick out some specific group or subset of groups that SSOSync would ignore from deletion (so a sync doesn't undo the temporary change).