stxho (stxho) asked a question.
At my company's Okta org we many apps and all of the usernames of these apps are set by the app. When a name changes to an existing user in our profile masters/sources some of the apps update username when the related field updates while other apps do not do this. All of the apps in question are SAML. I'm going to reference Email as the Username since that is the most common setup for our apps (but this is also a problem for some other fields set as username). Several apps, when email is changed for userA, automatically get an updated username it seems. While other apps that also use email as username do not get updated automatically for userA.
We've noticed this primarily/only on name changes... users whose DisplayName in AD is changed and email address to match.... SAMaccountname and any other fields stay as the "old" name.
Note that none of the apps in question use a Custom expression/value to get email... it's simply chosen from the preset values in the dropdown on the App's "Sign On" tab...
Anybody know exactly what behavior should be expected in situation where properties in the profile source(s) change? Should I expect the usernames to update automatically at all?
Any ideas why we might be seeing some apps behaving one way while others another way?
Thanks!
John
So, I had put in a ticket before you answered since I wasn't getting traction on this post as fast as I'd hoped. And the answer turns out is there is a setting on the Sign On page that may be invisible in your org. It was in mine... Okta Support had to turn it on for our org... It's a setting just under the Username selection. It's labeled "Update application username on" with options: Create and update, or Create Only. Not sure why the setting wasn't showing. Or how some apps got set one way or another when I couldn't set that originally... I checked in Profile Mappings for an app that now shows as set to "on Create Only"... username is not set to override so therefore it is not set to "on Create Only" in the mappings (that selection only becomes available I think when you override mapping for username). My theory is that these were somehow setup that way in the original OIN template... just something the admin would never see during app creation or in settings afterward.