Update User Email Address Pushed via SCIM

andrew_isos

We recently changed the email address and display names of two users. The display names pushed via the SCIM as expected but the email addresses did not change. Is this expected behavior?

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

rudy

@andrew_isos,

can you confirm that the respective users received e-mails asking them to confirm the email address change?

andrew_isos

I checked with the two users, they did not receive emails about confirming their address changes.

rudy

@andrew_isos,

can you update your SCIM bridge install to v1.6.0 and attempt a similar change? it should result in the user receiving an email to confirm that they want to update their 1Password.com account's email address.

andrew_isos

I updated to v1.6.0 but neither user got an email afterwards. I searched the log from today and neither of their names appears in the log.

graham_1P

Hi @andrew_isos ,

Did you re-initiate the email change after updating the SCIM bridge to v1.6.0? As 1Password is strictly downstream of your identity provider, unless your identity provider re-tries the action, no changes will be made.

Graham

andrew_isos

I can't re-initiate the email change since it's already occurred in other systems, but I did force a provisioning sync from Okta to 1Password. Neither user in question has received an email and neither email address has been changed. Would the email go to the email currently in 1Password? That question is more out of curiosity. The old address is setup as an alternate email address for the accounts.

graham_1P

Hi @andrew_isos,

I think a little bit of the background on the feature may help answer some of your questions.

To directly answer your question, yes the email would go to the old email address on the account because it is still associated with their encryption key. Email changes on 1Password require user involvement because they are tied into the user's encryption key. When combined with a user's secret key and master password and a few other items, those items form a user's Master Unlock Key (MUK). For that reason, the user receives an email on their old email (tied to their existing encryption key) which then takes the user to an email change dialogue in the unlocked web app (with all their items and group memberships decrypted), and then their email is changed in 1Password, creating a new MUK, which is then used to re-encrypt all their items with the new encryption key.

To read more about the MUK and our encryption model, take a look at our security whitepaper, pages 23-28, the section titled "A deeper look at keys".

To expand in combination with my previous answer, if you updated to v1.6.0 after updating the users' email addresses in the IDP, no further changes will come from the IDP without your action. As the change cannot be re-initiated on the IDP end, you will have to get the users to change their email addresses manually, or manually send a PATCH request to the SCIM Bridge mimicking the change from the IDP. To manually change the emails, you will have to temporarily disable provisioning in 1Password.

I'd be happy to provide more detailed instructions if you are interested.

Graham

andrew_isos

Any detailed instructions in order to send a PATCH request from Okta to the SCIM Bridge would be much appreciated.

Also, can you confirm that these actions (email address proposed change and emails being sent) are something I can expect to see in the SCIM log?

graham_1P

Hey @andrew_isos,

Email changes are something you should expect to see in the changelog. It should look something like:

[LOG] [1.6.0] 2020/11/10 17:37:12 (INFO) Starting email change (jon.snow@company.com -> jon.stark@company.com) for user with email jon.stark@company.com

I misspoke earlier: It is a PUT not a PATCH. That would look like:

curl -X PUT -H "Authorization: Bearer $YOUR_TOKEN" -d @emailchange_body.json https://scim.company.com/Users/$USER_UUID

where $YOUR_TOKEN is your SCIM Bridge bearer token, scim.company.com is your SCIM Bridge domain, and $USER_UUID is the UUID of the user in question. You can get that via a query to your bridge like:

curl -X GET -H "Authorization: Bearer $BEARER" https://scim.company.com/Users?filter=userName%20sw%20jon

The body of the PUT (emailchange_body.json) would like something like:

{"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],"userName":"jon.stark@company.com","name":{"givenName":"Jon","familyName":"Stark"},"emails":[{"primary":true,"value":"jon.stark@company.com"}],"externalId":"00ukky9mne4FINKqw0h7","groups":[],"password":"9Jx3Y96d","active":true}

For more information on any of the queries, take a look at RFC 7644

Let me know what follow up questions you have.

Graham

wooder

I'm trying to do exactly the same thing - change an email address in Okta and have it reflect in 1Password. The logs from the SCIM server respond with an error 441 when the change is sent.

2020-12-07T21:45:01.656394829Z [LOG] [1.6.0] 2020/12/07 21:45:01 (ERROR) PutUserHandler failed to UpdateUserWithSCIMUser: failed to change users email: 441:
2020-12-07T21:45:01.657563695Z [LOG] [1.6.0] 2020/12/07 21:45:01 (INFO) 500 (Internal Server Error) Failed to update user

Okta reports an error as well. How can we resolve?

graham_1P

Hi @wooder

Can you please confirm you have added the new email change domain to your list of allowed domains? If it is not included in he list the domains on the invites page, the email change will fail.

I agree that is not clear from the information you are given. We are working on making that error line more clear.

Let me know if that fixes your issue.

Graham

wooder

@graham_1P thank you so much! That was it!

graham_1P

No problem. Let us know what further questions you have!

Graham

yennik

Hey all, just because I haven't seen this documented anywhere but it was mentioned as on the radar, updating email changes when SCIM is used with Azure AD doesn't work/isn't supported. The work around provided is using the curl command provided by Graham above. Fingers crossed to get Azure AD support soon! Thanks...

1P_Amanda

Thank you for updating this! It's on our radar - keep an eye out in the coming months :)