Groups not syncing: invalid character '*' looking for beginning of value

[Pitta]

Describe the bug After initial config/setup, I'm getting the following error:

{ "level": "fatal", "msg": "Notifying Lambda and mark this execution as Failure: invalid character '*' looking for beginning of value", "time": "2023-08-17T18:14:03Z" }

This is coming from the deployed application in AWS

To Reproduce Steps to reproduce the behavior:

1. deploy app via marketplace
2. use name:* for GoogleUserMatch
3. use name:com-aws-* for GoogleGroupMatch
4. shouldnt need to fill in IncludeGroups, but i cant leave it blank.... so name:com-aws-*

See error logs

Expected behavior The any group with the prefix com-aws- synced to AWS IAM Identity Center, along with any members of those groups.

Additional context I've got a bunch oof users synced, but no groups.

[ChrisPates]

The Google admin api does not allow you to use just a ‘*’ wildcard. There needs to a prefix or suffix.

You can test this directly against the api tool for the Google admin console.

Chris

On 17 Aug 2023, at 19:23, Justin Pitta @.***> wrote:



Describe the bug After initial config/setup, I'm getting the following error:

{ "level": "fatal", "msg": "Notifying Lambda and mark this execution as Failure: invalid character '*' looking for beginning of value", "time": "2023-08-17T18:14:03Z" }

This is coming from the deployed application in AWS

To Reproduce Steps to reproduce the behavior:

1. deploy app via marketplace
2. use name:* for GoogleUserMatch
3. use name:com-aws-* for GoogleGroupMatch
4. shouldnt need to fill in IncludeGroups, but i cant leave it blank.... so name:com-aws-*

See error logs

Expected behavior The any group with the prefix com-aws- synced to AWS IAM Identity Center, along with any members of those groups.

Additional context I've got a bunch oof users synced, but no groups.

— Reply to this email directly, view it on GitHub https://github.com/awslabs/ssosync/issues/144 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVULYNDYPI6DD3RRUFXLYDXVZOTLANCNFSM6AAAAAA3UOXN4Q . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/ABVULYITLZZUCCZZAYKC67LXVZOTLA5CNFSM6AAAAAA3UOXN4SWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHG5GFDPQ.gif Message ID: @.***>

[Pitta]

So how do people target any users in a group without name:*?

This may just me being super thick here, but the docs are not clear enough for me to discern basic functionality here.

Am I using the native SCIM sync just for users based on thier assignment to the app, and then JUST using this tool to sync groups? If so, can I just slap anything in the user search field since it is being handled elsewhere? How would this know to add the synced users to the synced groups?

[ChrisPates]

So it should be one method or the other this open source project filled a need before the native integration was released.

The configuration has got a little ‘involved’ since v0.8 where a second configuration pattern was introduced. I have a branch in which I was working on a major refactoring of the match behaviour, which would allow for just the confirmation you’ve tried. However, I have had time to commit to this project recently.

Assuming you want to do sync based on group membership, put the prefix string under the group match and leave the user match empty. The user match is run in addition to the user discovered through the group match.

Chris

On 17 Aug 2023, at 20:04, Justin Pitta @.***> wrote:



So how do people target any users in a group without name:*?

This may just me being super thick here, but the docs are not clear enough for me to discern basic functionality here.

Am I using the native SCIM sync just for users based on thier assignment to the app, and then JUST using this tool to sync groups? If so, can I just slap anything in the user search field since it is being handled elsewhere? How would this know to add the synced users to the synced groups?

— Reply to this email directly, view it on GitHub https://github.com/awslabs/ssosync/issues/144#issuecomment-1682813388 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVULYMV5V25D2GX4AMZSCDXVZTMTANCNFSM6AAAAAA3UOXN4Q . You are receiving this because you commented. https://github.com/notifications/beacon/ABVULYN4HCNRYRGFN2ONEM3XVZTMTA5CNFSM6AAAAAA3UOXN4SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTEJWY4Y.gif Message ID: @.***>

[Pitta]

I appreciate your responses!

We tried doing user + group sync natively with SCIM and the built in functionality in AWS, but we got direct confirmation from AWS that groups are still not supported natively yet. They directed me to this tool, that was supposedly maintained by AWS.

How would you suggest I send nothing to fields that are marked as "required"?

[Pitta]

To add to my confusion, the official AWS documentation on using this tool has contradictory information to your suggestions here.

https://catalog.workshops.aws/control-tower/en-US/authentication-authorization/google-workspace/3-provisioning-scim

Specifically...

SSOSyncFunction GoogleGroupMatch : name: GoogleUserMatch : name: IgnoreGroups : none IgnoreUsers : none IncludeGroups : * LogFormat : leave as default LogLevel : leave as default ScheduleExpression : leave as default SyncMethod : leave as default

[Pitta]

I've redeployed the whole thing, using some sane queries for the fields that are required but skipped. Getting 403's now so I have some other setup to suss out now.

Thank you for your help here. We can close this now if appropriate.

[ChrisPates]

Leave it with me.

I’m not sure why that lab has been changed to those settings because they will not work. So clearly it hasn’t been test run with those settings.

Kind regards,

Chris

On 18 Aug 2023, at 22:09, Justin Pitta @.***> wrote:



To add to my confusion, the official AWS documentation on using this tool has contradictory information to your suggestions here.

https://catalog.workshops.aws/control-tower/en-US/authentication-authorization/google-workspace/3-provisioning-scim https://catalog.workshops.aws/control-tower/en-US/authentication-authorization/google-workspace/3-provisioning-scim

Specifically...

SSOSyncFunction GoogleGroupMatch : name: GoogleUserMatch : name: IgnoreGroups : none IgnoreUsers : none IncludeGroups : * LogFormat : leave as default LogLevel : leave as default ScheduleExpression : leave as default SyncMethod : leave as default

— Reply to this email directly, view it on GitHub https://github.com/awslabs/ssosync/issues/144#issuecomment-1684437995 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVULYMQD7WLGZ3CDDGCT2TXV7KYRANCNFSM6AAAAAA3UOXN4Q . You are receiving this because you commented. https://github.com/notifications/beacon/ABVULYJ5JV5HRT2DIOVBV23XV7KYRA5CNFSM6AAAAAA3UOXN4SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTEMZ56W.gif Message ID: @.***>

[Pitta]

Wanted to jump in here and follow up.

I JUST got this working. After the config tweaks you suggested I was able to work with the privilege issues on the google side and finally got a syncing group!

Thank you again @ChrisPates for your help and patience.

I did want to add, updating the application in AWS by updating the running stack and editing the values in the config is fraught with issue. When updating a value, if any of the others are showing up masked with , it will _APPLY TO THOSE VALUES!_. So when updating, I went in and re-pasted everything in, otherwise I'd keep getting the same error in my initial issue description.

Also - values that are "only needed if using a different strategy" are still requited to fill in. I know this is probably a CloudFormation dependency, but it might be a good idea to have a default value that the app knows to ignore pre-populated instead of the current flow which is not ideal.

[ChrisPates]

So these are the parameter that should appear in that lab.

SSOSyncFunction
GoogleGroupMatch : name:AWS*
GoogleUserMatch : *
IgnoreGroups : none
IgnoreUsers : none
IncludeGroups : *
LogFormat : leave as default
LogLevel : leave as default
ScheduleExpression : leave as default
SyncMethod : leave as default

However, the screenshots are also of a significantly earlier release of ssosync. So I'm looking to get that lab updated and end to end tested.

I concur on the defaults, I'm going to update them to the above.

[ChrisPates]

Since this the parameter validation has been overhauled and should provide better guidance and allow for empty fields where appropriate.