Hi all,
We're migrating AWS IAM Identity Center provisioning from Okta SCIM to Google Workspace using ssosync and have a few questions before we run --dry-run in our test environment. Happy to share findings back here once we've validated.
Our setup:
AWS Organisations enabled (management account: [REDACTED])
Delegated Administrator account assigned
~40 Okta-provisioned groups currently in AWS Identity Center
Google Workspace with custom attribute schema: Single_Sign-On.AWS_Username (API key: Single_Sign-On with a hyphen)
Several users with external-domain emails whose AWS_Username differs from their primary Google email
Control Tower in use — aware of issue #88
Q1 — How does ssosync name/identify groups in AWS Identity Center?
When ssosync creates a group in AWS Identity Center, does it use the Google Group display name or the Google Group email address as the group's display name in Identity Center?
We have existing Okta-provisioned groups in AWS with display names like EH AWS Users, and the corresponding Google Group is App-AWS / app-aws@[company-domain].com. We want to know what to rename the existing AWS groups to before the first ssosync run so it takes ownership rather than creating duplicates.
Q2 — Will ssosync take ownership of an existing AWS group if the name matches, or always create new?
If we rename an existing Okta-provisioned AWS Identity Center group to match what ssosync expects (from Q1 above), will ssosync detect the existing group and sync into it — preserving all permission set assignments — or will it always create a brand new group and leave the old one?
Q3 — Custom Google attribute for username matching (AWS_Username)
Our users have a custom Google Workspace attribute (customSchemas.Single_Sign-On.AWS_Username) that holds their AWS username. For external-domain users this differs from their primary email. What is the exact ssosync flag or config parameter to tell ssosync to use this custom attribute for username matching instead of primary email?
We've seen references to --user-match and AWS_SSO_USER_MATCH in the docs but want to confirm the exact syntax for a custom schema attribute.
Q4 — --group-match filter and Control Tower group safety
We plan to use an aws-* prefix on all Google Groups we want synced, and set --group-match accordingly. If ssosync only matches Google Groups with that prefix, will it completely ignore AWS Identity Center groups that don't match the filter (e.g. Control Tower groups like AWSControlTowerAdmins)? Or does ssosync still evaluate and potentially delete unmatched AWS groups?
Thanks in advance — happy to post our dry-run results back here once we've tested.
Hi all,
We're migrating AWS IAM Identity Center provisioning from Okta SCIM to Google Workspace using ssosync and have a few questions before we run --dry-run in our test environment. Happy to share findings back here once we've validated.
Our setup:
AWS Organisations enabled (management account: [REDACTED])
Delegated Administrator account assigned
~40 Okta-provisioned groups currently in AWS Identity Center
Google Workspace with custom attribute schema: Single_Sign-On.AWS_Username (API key: Single_Sign-On with a hyphen)
Several users with external-domain emails whose AWS_Username differs from their primary Google email
Control Tower in use — aware of issue #88
Q1 — How does ssosync name/identify groups in AWS Identity Center?
When ssosync creates a group in AWS Identity Center, does it use the Google Group display name or the Google Group email address as the group's display name in Identity Center?
We have existing Okta-provisioned groups in AWS with display names like EH AWS Users, and the corresponding Google Group is App-AWS / app-aws@[company-domain].com. We want to know what to rename the existing AWS groups to before the first ssosync run so it takes ownership rather than creating duplicates.
Q2 — Will ssosync take ownership of an existing AWS group if the name matches, or always create new?
If we rename an existing Okta-provisioned AWS Identity Center group to match what ssosync expects (from Q1 above), will ssosync detect the existing group and sync into it — preserving all permission set assignments — or will it always create a brand new group and leave the old one?
Q3 — Custom Google attribute for username matching (AWS_Username)
Our users have a custom Google Workspace attribute (customSchemas.Single_Sign-On.AWS_Username) that holds their AWS username. For external-domain users this differs from their primary email. What is the exact ssosync flag or config parameter to tell ssosync to use this custom attribute for username matching instead of primary email?
We've seen references to --user-match and AWS_SSO_USER_MATCH in the docs but want to confirm the exact syntax for a custom schema attribute.
Q4 — --group-match filter and Control Tower group safety
We plan to use an aws-* prefix on all Google Groups we want synced, and set --group-match accordingly. If ssosync only matches Google Groups with that prefix, will it completely ignore AWS Identity Center groups that don't match the filter (e.g. Control Tower groups like AWSControlTowerAdmins)? Or does ssosync still evaluate and potentially delete unmatched AWS groups?
Thanks in advance — happy to post our dry-run results back here once we've tested.