Spring Security in NixMash Spring App: The Parts You Can See

I subtitled this post “The Parts You Can See” because the more I work with Spring Boot it becomes clear how much is done for you behind the scenes. Spring Security is no exception, because as you’ll see there is relatively little code required to produce a working Web Security architecture.

Spring Security will be a feature of NixMash Spring v0.1.6. The app is evolving nicely with a number of features yet there aren’t that many classes. Spring Security maintains that tradition by adding only 5 classes in the MVC module and 4 in the JPA module.

SecurityConfig, CurrentUserController, CurrentUser, CurrentUserDetailsService and SecurityWebAplicationInitializer are added in MVC.

User, Authority, UserProfile and UserRepository are added in the JPA Module.


SecurityConfig is our starting point and is shown below. You’ll notice we use the @EnableGlobalMethodSecurity Annotation for the class and extend the WebSecurityConfigurerAdapter class.

  1. Various Url Resources are defined for PermitAll(), Ignore, isAdminRole(), etc.
  2. We use a custom CurrentUserDetailsService that extends Spring Security’s UserDetailsService to populate our CurrentUser Principal Object.
  3. An Inner Class when using the H2 Profile to configure Admin access to H2Console
  4. An Authentication Builder using our @Autowired UserDetailsService (which in turn uses an @AutoWired UserRepository found in our JPA Module)
  5. Specifies urls to be ignored, like /webjars/**, /static/**, etc.
  6. Defines the Url Path permissions which we’ll look at next.

Url Path Permissions

The configure(HttpSecurity) Override method is below. It’s incredible, really, how many functions are performed by a few lines of code. We begin by specifying which pages can be accessed anonymously and which require authentication.

Sidebar: The Inner Class (#4 above) that configures the H2Console for ADMIN access isn’t shown. We’re using an Inner Class because H2Console requires CSRF disabled and one or two other configuration changes to work properly, otherwise we could have simply included it here with hasRole(“ADMIN”).

Some of the other functions the code below is performing is specifying the login page and what to do if there’s a login error. We’ve got a full working “Remember Me” implementation with the inclusion of a simple .rememberMe() and we’ve defined our Access Denied page.


We’re using a custom user object which extends Spring Security userdetails.User and populates our JPA Module’s User Model object.

Displaying the Authenticated User in Thymeleaf

At the bottom of each page we’re displaying the authenticated user in Thymeleaf.

Here’s the Thymeleaf HTML which displays the footer User info. For kicks we’re displaying the user two ways, first using the currentUser model object (more on that in a second.) We’re also using Thymeleaf’s Spring Security Dialect with sec:authorize=”isAuthenticated()” starting that section.

Back to the CurrentUser

So how does the Thymeleaf client know about CurrentUser? We created a CurrentUserController class annotated with @ControllerAdvice so that all MVC methods include the CurrentUser.

There are other cool parts of Spring Security in the app which you can see. Those and all of the source code in this post can be found in the v0.1.6 branch of NixMash Spring on GitHub.