SEC-2806: UserDetailsManager should know about the password encoder

Mauro Molinari (Migrated from SEC-2806) said:

UserDetailsManager (in particular JdbcUserDetailsManager) has write methods that allow to write user (and password) information or change passwords on the backend repository (i.e. a database for JdbcUserDetailsManager).
The changePassword(String, String) method, for instance, takes the old and new passwords, tries to verify that the old password is correct and then writes the new password to the backend repository.
However, the way in which passwords are handled by a UserDetailsManager implementation is inconsistent: for instance in JdbcUserDetailsManager changePassword(String, String) calls org.springframework.security.authentication.AuthenticationManager.authenticate(Authentication) to verify the old password, so this means that the old password is expected to be not encoded (the actual encoding for comparison is performed by the AuthenticationManager), however then the new password is written as is to the database.
In other words, for this to work correctly, the calling code should pass the old password not encoded and the new one already encoded, which seems confusing and inconsistent to me.

IMHO the UserDetailsManager should have a passwordEncoder property that the user can set to specify which passwordEncoder should be used to write password information to the repository backend.

Start by reading UserDetailsManager and its JdbcUserDetailsManager implementation, especially changePassword(String, String), then trace how AuthenticationManager verifies the old password. Done should establish a consistent password-encoder configuration for writing new and changed passwords across the relevant UserDetailsManager implementations.