Clear expectations of sync modes

[paveq]

Describe the bug
Ssosync unexpectedly creates and deletes users when sync_method is set to groups.

Expected behavior
Sync_method groups should only create, delete and edit group membership, and not create or delete Identity Center users. At minimum it is not clear in documentation, and assumption could be made that groups method will sync only groups and their membership, and users_groups would create and delete also users.

Additional context
In my case I've already configured regular SCIM provisioning from Google Workspace to AWS IAM Identity Center. Having ssosync touching these users feels a bit redundant.

[ChrisPates]

Ssosync unexpectedly creates and deletes users when sync_method is set to groups.
Expected behavior, the two sync modes a not very well named and the users_groups was replaced by groups after moving to v1.x.

users_groups sync the whole directory ignoring based on an explicit list of user email addresses and group email addresses. This option will be deprecated in v3.x, along with a number of other changes to simplify usage.

groups sync a sub set of the directory based on group match (and their members) and user match comma separated lists of queries, a "*" in either will sync all groups (and their members) and all users. You can explicitly ignore groups and users using the the relevant fields.

ssosync should not be used in combination with the official integration, they are mutually exclusive.

• If you want full support from AWS & Google, but don't need group support then the official integration is for you.
• If you need groups support then ssosync is you best option.

At this point in time, I would strongly recommend ignoring the sync_method option, and let it default to groups.

The documentation have been updated recently but the is definitely work to be done.

In terms of a simple guide that shows you how to get started I would recommend this Google Workspace lab in the AWS Control Tower Workshop.

[srdjantodorovic-SH]

@ChrisPates

This option will be deprecated in v3.x

So, an use case where it is needed to sync only these groups: billing@company.com, dev-team@company.com, qa-team@company.com, and ignore the other groups (e.g. devops-team@company.com) will not be possible?

[ChrisPates]

So version 2 onwards the 'what to sync' shifted to using the directory query filter, to make it more flexible and efficient. So the selective sync capabilities not being lost.

So that's is entirely possible it would just use a GroupMatch like:
email=billing@company.com,email=dev-team@company.com,email=qa-team@company.com or you can wildcard
email:billing@*,email:dev-team@*,email:qa-team@*.

It is typical to be performing a partial sync based on a set of groups or a prefix to the name of the groups: name:AWS_* for example.

I've worked with customer with directories into the 100K+ users but only syncing 5-10k of them.

[srdjantodorovic-SH]

Thanks! I just discovered it with experimentation and info from other issues. It would be useful to have some complex examples like that in the README.

I'm glad to hear that it is not going away as it seems very useful, like you said.