dsmrt
commented
5 years ago No worries. This is a great question. Unfortunately, I don't know of a simple solution for this.
We have this issue with some of our clients and have had to resolve them manually within craft.
In SAML terms, username is sent over within the NameID field which is the unique ID for the user. The plugin uses that value for the Craft username. Looking within OKTA, it looks like they force the username to be an email which makes things tricky while maintaining SSO. The goal might be to see if you can use a unique id (that never changes) as the NameID value. But then you have to deal with migrating existing users to the new username format which might be a pain.
You can see my example of the application username being set to NameID (in OKTA) in the screenshot below.
Ultimately, unless you have a ton of email changes, it might be best to handle them as them come in and merge the users manually. OKTA may have some webhook capabilities where you can watch for username changes but that might be more work than what it's worth.
I know this doesn't solve your issue but I hope this helps. Let me know if you have any other questions.
benjaminkohl
My apologies for posting a question as a github issue but when I clicked the "Support" link on the plugin page, this is where it took me.
I was wondering if there is a way to reconfigure how an existing user is uniquely identified by the plugin? We've had a few cases where our client's users change their email address in Okta and this results in the creation of a new Craft user rather than updating their Craft account to use the new email address.