The UserDetailsManager interface

We have already leveraged the InMemoryUserDetailsManager class in Spring Security in Chapter 3, Custom Authentication, to look up the current CalendarUser application in our SpringSecurityUserContext implementation of UserContext. This allowed us to determine which CalendarUser should be used when looking up the events for the My Events page. Chapter 3, Custom Authentication, also demonstrated how to update the DefaultCalendarService.java file to utilize InMemoryUserDetailsManager, to ensure that we created a new Spring Security user when we created CalendarUser. This chapter reuses exactly the same code. The only difference is that the UserDetailsManager implementation is backed by the JdbcUserDetailsManager class of Spring Security, which uses a database instead of an in-memory datastore.

What other features does UserDetailsManager provide out of the box?

Although these types of functions are relatively easy to write with additional JDBC statements, Spring Security actually provides out-of-the-box functionality to support many common create, read, update, and delete (CRUD) operations on users in JDBC databases. This can be convenient for simple systems, and a good base to build on for any custom requirements that a user may have:

If UserDetailsManager does not provide all the methods that are necessary for your application, you can extend the interface to provide these custom requirements. For example, if you needed the ability to list all of the possible users in an administrative view, you could write your own interface with this method and provide an implementation that points to the same datastore as the UserDetailsManager implementation you are currently using.