Google Workspace SCIM integration - sync not working after intial sync

@"laz.h_1P"

Thanks for the sync button - really appreciate it!

As for the other limitations you've noted, these are mostly by design.
I'd argue it's a bad design then imo - this sync must be improved to be practical. Also the current behaviour (that it only listens to changes made by the Admin API) should be mentioned explicitly in the integration docs as limitation.
Only listening to change events from the Admin API - which can be missed when a admin adds group members through groups.google.com - is imo a big security risk. What if there is a user in a privileged group and we want to remove him? In the current design it can happen that the user remains in the privileged 1password group forever - unknowingly.
considering that the desired state can be reached by running a sync that's the solution we will recommend for now.
Running a sync might be a solution but this must be fully automatic and happen on a regular, reasonably short interval (like every 10 minutes). It's not practical for an admin to go manually to the admin page every hour to click the sync button to ensure the 1password group is sync is working.

on direct/indirect group memberships:

We have no concept of nested groups in 1Password, so we opted to flatten out the group memberships and require a direct sync.
I don't think the sync does any flattening at the moment. In fact I think this what you should do: Have the scim bridge traverse the group hierarchy (incl. nested groups), get all the direct+indirect members and then add all the google group members (direct or indirect) as direct members into the corresponding 1password group. This is what actual "flattening" would look like.

Best, Christian

I'm also experiencing issues having set this up today....

Initial sync works and then subsequent users are not provisioned - the logs indicate that the session has expired; nothing seems to trigger issuing a new session. As a workaround at the moment - I am manually restarting the service every time I want to add/remove users, which is not ideal.

Hi @geekflyer,

I'm happy to announce that our latest version of the SCIM bridge does include a sync button that you can click on demand. Feel free to upgrade using whichever deployment method you originally chose.

As for the other limitations you've noted, these are mostly by design. We only subscribe to events triggered by admin users using the Google admin report API (which is part of the scope permissions you give us during the initial setup). We can look into triggering these notifications through other means if the demand is high enough, but considering that the desired state can be reached by running a sync that's the solution we will recommend for now.

When it comes to direct / indirect group memberships, this is intentional. We have no concept of nested groups in 1Password, so we opted to flatten out the group memberships and require a direct sync. If you have a group of a group that you would like synced, you just have to check both groups in the UI instead of only the parent one.

Thanks a ton for your feedback, and we hope to see you again soon!

Hi hemal.

I send your support a couple of days ago the SCIM bridge logs but haven't received a response so far.
Anyways I did some more digging and I think I found what the issue is:
The SCIM bridge only appears to get notified of changes in group members when a GSuite Admin makes them via admin.google.com but not when group members get changed via groups.google.com (irrespective of whether a Gsuite Admin or another member performs the action).
So when one adds or removes members via groups.google.com 1password simply ignores the change.

Could you please look into fixing this?

There's a few other limitations I noticed:
1. once a 1password group is out of sync with the google group (due to the previously mentioned bug) it's pretty hard to get it back in sync. The only way is basically to add/remove a random group in the SCIM bridge to force-trigger a complete resync. Imo the SCIM bridge or 1password integration UI should have a button to force trigger a resync (as mentioned also by https://1password.community/discussion/comment/658945/#Comment_658945 ). Furthermore the bridge should run a full sync every 10 minutes or so to reconcile inconsistencies when it missed notifications from GSuite
2. The SCIM bridge only syncs direct google group members but no indirect google group members (i.e. members which are part of a group of a group).

I think given all the current limitation/bugs the Google Workspace SCIM bridge is not usable for us, so we will deactivate it for now.

Looking forward for the improvements!

Thanks!

Hello @geekflyer ,

Thank you for the question.
Happy to know you are able to perform SCIM integration with recent released version.

My pleasure to assist you.
I appreciate the efforts you put in around investigation. Though the scenario you mentioned is strange and should not take place. I assume the moment you perform changes in Google group, you are maintaining authenticated connection with your SCIM bridge.

Sync between Google workspace Groups and 1Password account happens every 24 hours. But there is no time delay for reflecting changes in your 1Password account. Changes being made from Identity provider by push notification happens immediately. If you are not seeing changes immediately its probably something wrong with push notifications. It would be great if you can download logs from SCIM Ui and attach here for diagnosis.

@geekflyer Yes, less than a minute for sure. Probably less than 30 seconds between when I added the user to the group and when I checked in 1Password.

timchambers cool thanks for your experience! I wonder how long did it take until the user was visible in 1pw? Was it kind of immediate (like less 30 than seconds?)?

@geekflyer I tested adding an existing Google Workspace (GW) user to an existing group, and the corresponding user was added to the corresponding group in 1Password automatically as expected. Per your note in my other thread, I don't think I'm experiencing the issue you mentioned. The issues I described above seem to happen only when the capitalization of the email address of the user in GW differs from the user in GW.