GregK.54397 (Customer) asked a question.
We've started seeing these errors pop up in our Okta org recently. According to other posts, okta has started flagging first names that contain a dot ('.') character.
But the validation seems inconsistent:
These names are considered 'malformed'
-- first.com
-- first.edu
However these are not considered malformed
-- first.xxx
-- first.com.xxx
It seems like the rule is that firstname can contain a dot, as long as it doesn't end with a valid Top Level Domain (.com, .edu, .org, etc.).
>>>> Can somebody explain, or point to a document that explains the full, actual requirements for a valid firstname in Okta?
Also, I've seen a case in which a user already existed with a malformed first name, and when attempting to update their login via API call, the response is "firstname: the field is malformed".
>>>> Can someone confirm that this is indicating that you can't make any profile changes to a user that currently has a malformed firstname?
Hi @GregK.54397 (Customer) , Thank you for reaching out to the Okta Community!
I’ve looked into this and from what I found a new feature was introduced preventing attribute values in the abc.def format from being present in certain Okta user attributes. The intent being to reduce the risk that a phishing link could be present in an Okta user profile created via Self-Service Registration by a bad actor.
It’s my understanding that this is not yet fully deployed across all Okta cells as such it might not yet be covered by the Release Notes or a specific documentation.
If this feature is interfering with your implementation, please open a case with my colleagues from the Support team to perhaps have it disabled or at least clarify expected behaviors and limitations.
If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you.
Hope my answer helps!
--------------------------------
Ask the experts about Okta Privileged Access
Thanks for the reply, but my observation (as noted in the original post) is that not all strings in abc.def are considered malformed - but only those that end with a valid top-level domain. Can you please confirm this as being the actual implementation of the new restriction?
Also can you please provide a comprehensive list of the "certain Okta user attributes" to which this applies?
That would be a question for my colleagues from the Support team. They would be able to check with the Product team responsible for the feature.
Unfortunately, I don’t currently have access to more information than the one already provided.
Regards.
--------------------------------
Ask the experts about Okta Privileged Access
Hi @GregK.54397 (Customer), in the meantime, do you have a list of he "certain Okta user attributes" to which this applies? We are facing the same issue.
Thank you in advance!
The most specific answer I could get from Okta Support is
"We know this release added additional malformed field validation to guard against invalid misuse of the First and Last name fields—for URL formats as you've noted and HTML tags. There has been no communication that further changes or constraints to fields other than user.firstName and user.lastName have been made and we have not observed."
They were unable/unwilling to give me explicit definitions and scope of these changes. I get the impression that Support is just guessing what their Development team implement through observation, instead of having in their possession the actual specs defining what the new validations are.