Multiple methods of the IdentityServiceImpl call specific commands that make use of features of the UserEntity rather than just the User (e.g. SaveUserCmd that checks the password against the policy). Those usages of the UserEntity could also be done by the specific Identity Provider, like the DbIdentityServiceProvider.

When customers write their own identity providers, they cannot easily reuse the IdentityServiceImpl as this now has a tight coupling to the UserEntity. By breaking this coupling and letting the provider take care of the type-specifc User class actions, we would allow to reuse the IdentityService in custom implementations.

--------------------
original description:
Right now, when a user is saved the saveUser method in the IdentityServiceImpl class is called, which uses the SaveUserCmd class implementing the Command interface. This class casts the User object into UserEntity. Now, when implementing a custom identity provider, we would generally want to use our own user store and structure which would almost certainly be incompatible with UserEntity. This casting in SaveUserCmd is preventing the use of the default IdentityServiceImpl and as a workaround, I have to rewrite the save methods in a custom IdentityService.

If the SaveUserCmd doesn't cast to UserEntity and all actions that needs to be performed on the UserEntity like calling the checkPasswordAgainstPolicy is delegated to the default identity provider instead, then there is no real need to override the default identity service itself which seems like a better design to me.

The above issue is also present while saving groups and tenants.