[keycloak-user] Users with no firstName and lastName?

["Matthias J. Déjà"]

Hello,

new user here, so please forgive oversights on my part.
After reading the documentation and searching the mailing list, I did not find this question answered.

I am creating a user storage SPI implementation that is backed by an external user storage.
That external user storage does not have first or last names for users.
The only intrinsic information for a user on the external storage is a unique username and the password.

The Keycloak user storage SPI that I am about to implement will make the users available in Keycloak, such that they can be displayed, created and edited via Keycloak.
Authentication will also be possible.

Here is the problem:
In Keycloak, first name and last name are intrinsic properties of a user.
(I am thinking of AbstractUserAdapterFederatedStorage, which I understand would be a good idea to implement.)

This is what I imagine as a realistic solution:
- In Keycloak, first and last name are still, in principle, present. But they are always empty.
- They cannot be changed.

The last point is important, as I do not want data to be split among Keycloak and the external user storage.
When a Keycloak user can successfully set the first/last name of a user, this implies that this is a meaningful operation.
Therefore, I would like to make those fields empty and non-editable.

What would be the best way to achieve this?
Do you see another way that would be better?

My current working hypothesis would be one of those:
A) Override setFirstName and setLastName to throw an exception that the Keycloak UI can deal with. (Which one?)
B) Have the storage return an unsuccessful result when attempting to store a user with non-empty values on any of those fields. (How exactly?)
C) Before storing a user, simply hardcode an assignment to firstName and lastName with either null or the empty string. (That would mean silently ignore changes to those fields and pretend that storing went okay.)

Thanks for your input.
Matthias Deja.