Google Workspace SCIM bridge not syncing group members when email address case differs

timchambers

I just deployed 1Password SCIM bridge v2.6.0 for Google Workspace on GCP (thanks for releasing that!)

One weird scenario I'm hitting is that for an as-yet-unknown reason[1], some of our 1Password users email addresses begin with a capital letter, when their corresponding Google account email addresses do not (e.g. John@example.com in 1Password, john@example.com in Google Workspace). Because of that difference, while john@example.com and jane@example.com are both members of the group foo-group@example.com which is now syncing to 1P via 1P SCIM bridge, Jane appears in the corresponding 1Password group, but John does not.

As best I can tell, this is because John got added to 1Password as with an uppercase first character in his email address (John@example.com) rather than lowercase john@example.com.

What's the best path for resolving this conflict? I'd ultimately like to make sure the emails in 1Password match the case of the emails in Google, but I don't see a straightforward way of correcting the user email address in 1Password.

[1] This case issue is probably happening further up the provisioning chain as we have a payroll system connected to Google Workspace that provisions new Google accounts for new employees, and is probably upper-casing the email address.

---

1Password Version: 8.9.4
Extension Version: 2.3.7
OS Version: macOS 12.6
Browser:_ Chrome

geekflyer

I might have a similar, but different problem (see https://1password.community/discussion/133801/google-workspace-scim-integration-sync-not-working-after-intial-sync#latest ). For me the initial sync is working but no sync afterwards when the google group has changed. Haven't seen a difference in email casing. I wonder if you managed to test out the behaviour when you add or remove a member from Google group? Does this successfully trigger a sync and how long is the delay? For us this doesn't seem to be working at all.

timchambers

@geekflyer I'll follow up with specifics in your thread, but I don't think this is the same issue.

I'm currently working on some tests renaming one such user in GW to something temporary, then renaming them back (with correct capitalization). I will report back on whether that solves the issue. Is there a way to force that rename only on the 1Password site?

hemal.g_1p

Hello @timchambers ,

Thank you for the question.
Happy to know you are able to setup SCIM integration with Google Workspace.

With reference to your question for differing email addresses I would like to ask if those users are manually invited to 1Password or provisioned by SCIM ?
We are unable to reproduce this particular scenario because email addresses are forced to be lowercase on Google Workspace.
Also it will be great if you can download logs from SCIM Ui and attach here for further diagnosis.
Any information on how you set up 1Password or how you encountered this issue will be helpful.

timchambers

@hemal.g_1p I've confirmed that the users were manually invited to 1Password with a capitalized email address (my hunch is that this was done on a mobile device and your input field allows autocorrect to capitalize things?)

I'll see if I can post some logs for you. Is there a particular event you're wanting to see in the logs? If so I can try and recreate it and capture that set of logs.

In the mean time, is there a way to trigger a user email change directly in 1Password? I know that the SCIM can trigger a email change when the email is changed in Google Workspace, but rather than going through the trouble of doing that multiple times for each user, if I could do so via the 1P API or the SCIM API, that would be simpler on our users.

Chas_1P

Hey @timchambers,

Thanks for reaching out and bringing this up. I was able to reproduce the issue and its now something on our radar to fix, as we should be treating emails as case insensitive. No need to provide us with logs since we have seen the issue reproduced ourselves. Unfortunately our email change process is case-insensitive, so our server won't propose the new email change to your users if the only change is a case change. The issue is very clear, and especially since we don't have any workarounds for you, we're adding this up next to fix. I'm sorry we don't have an immediate solution for you. You can expect this to be included in our next patch release, 2.6.1. We're hoping to have this released in 1-2 weeks, with our downstream apps updated in 2-3 weeks. Please reach out to us if you have any additional questions.

timchambers

@Chas_1P Thanks for the update, glad you've got it identified. I look forward to the fix. Will the resolution take care of renaming our 1Password users, or just ignore case when syncing users/groups?

Chas_1P

@timchambers This patch will simply ignore case differences in your user's emails, so that syncing will work as intended.

timchambers

@Chas_1P Got it, thanks.