Spring Boot Security | Default Configuration

Reading Time: 6 minutes

If your a beginner wanting to learn about Spring Boot Security, you have to first understand how security is configured by default. This step by step tutorial is the perfect starting point to understand Spring Boot’s default security configuration. There’s also a hidden gem that has flown under the radar!

Spring Boot Security | Setup

I’m assuming your not completely new to Spring Boot due to the topic at hand, so let’s focus exclusively on Spring Boot Security. We need to get our Spring Boot application setup with the right security starter dependencies so everything can be auto-configured for us.

Starter dependencies in general aggregate related dependencies together and save us the time of manually registering Spring Beans that are needed by Spring.  Specifically, “spring-boot-starter-security” uses the Class SecurityAutoConfiguration  to auto-configure the default out of the box configuration for Spring Security.

Once you import/create the Spring Boot Project into the IDE, the following default project structure will be presented. No resources, no code, just a main Spring Boot entry point Class with @SpringBootApplication with the correct starter dependencies.

So what does this thing do?!

Spring Boot Security - Initial Project out of the box | MVP Java

Spring Boot Security | Default Configuration

Through the magic of Spring Boot auto-configuration, we get the following functional features setup by default ..

  • A default user with username”user” with a unique UUID password generated in console on every application deployment
  • Default login, logout page with sign-out functionality and error page
  • Default Authentication Manager implementation based on username and password
  • A content-negotiation strategy to determine what sort of authentication to trigger – Basic or Form-based Authentication
  • Secure/locked-down by default configuration: All web resources require all users to be authenticated via a username/password
  • Extra security protection for CSRF, XST, XSS attacks
  • A Strict HTTP Firewall – our gem 🙂

There are many more auto-configured features however, we’ll stick to the features we’ll be able to see and interact with through the web browser.

Spring Boot Security | Architecture Basics – Filters

The way Spring Security is implemented for web based applications is through a chain Servlet Filters standing in front your secured web resources. When a HTTP request is made like http://mvpjava.com/someURI , it must first go through a chain of Spring Security filters. The same is true for the HTTP response.

Analogy time .. think of your protected resources as an airplane and each filter in the chain represent different check points we face at an airport before being allowed to board the airplane. There’s the check-in counter, the security check point (take off you shoes, please!), the boarding counter at your terminal gate and then the final ticket check as your entering the airplane. I hate flying!

Each checkpoint between you and the airplane has a specific purpose and together they form a chain of security points that we have to go through – its the same with these Spring Security Filters. Of course, we have to go through a similar process when we step off the plane. However, some things will be different – like picking up your luggage for instance or maybe going through customs. The HTTP response will also go through the filter chain on the return back to the client however, it may not have to exercise the same exact path or behavior.

Luckily, Spring Boot registers and bootstraps all these Servlet Filters as Spring beans for us in the Spring application context. The bootstrapping process happens through a javax.servlet.Filter acting as a proxy called DelegatingFilterProxy. It serves as the bridge between the web.xml (mostly hidden and generated from us) and Spring’s Application Context.

Here’s a visual flow on how the Spring Security Filters work on your first attempt at logging into the application.

Spring Boot Security - Login flow - Filters | MVP Java

Running your first Spring Boot Security Application

At this point, we need to see this in action. STEP 1 – Deploy the Spring Boot application in your favorite IDE. If your interested in seeing this through a video tutorial then click below.
 
The web application gets deployed to the default embedded web server and the following occurs ..
  • The IDE console window reports the default user credentials which are needed to login (boxed in blue below – STEP 2 –  Copy the password). Also notice that I’ve underlined in red, some of the Spring Boot Security filters that have been created.

Spring Security Security - console out of the box | MVP Java

 

  • We have an out of the box default login page provided by the DefaultLoginPageGeneratingFilter. STEP 3 – Login using the default User setup for us out of the box with usernameuser” and the password you copied over from the console.
Spring Boot Security - default login page with creentials | MVP Java
That’s really practical but how did Spring Security know to display form-based authentication versus basic authentication? That’s were the content negotiation strategy that I mentioned above, comes in.

Basic Authentication vs. Form-based Authentication

Both use an authentication implementation based on username and password but are handled by different Spring Security filters, internally. We can see via the console output above that we get an out of the box UsernamePasswordAuthenticationFilter . This filter handles form-based Authentication and BasicAuthenticationFilter handle the Basic Authentication.

Basic Authentication uses an “AuthorizationHTTP header to carry over the username and password. You can’t customize the form (generated by browser) or support sessions. Very common between services communicating over API’s which then add an encryption layer above that, like SSL.

Form-based Auth is very flexible because it’s offers a programmatic solution. You code and customize an actual HTML <form> which is issued by a HTTP POST method with a default URL /login. The login form has to have specific default parameter names identifying the username and password fields as well. Those default names are by default “username” and “password” .. who would of guessed!?  This will allow Spring Security’s UsernamePasswordAuthenticationFilter to intercept and process it because that’s what it expects.

Here’s how the HTML code for the default login page looks like

 Spring Boot Security - Login Form code | MVP Java
Notice all the default are there boxed in red. The extra part at the bottom which is boxed in green is an extra security protection feature called CSRF (Cross Site Request Forgery). Spring Boot Security generates a CSRF token for form-based Auth in order to protect us from hackers trying to have their forms used in place of ours. Since they don’t know the token, they can’t forge the form post request.

  Default Spring Boot Security Error and Logout Page

We have now successfully logged in but we have no place to go yet since we haven’t told Spring where are welcome/home page is. Therefore, we are met with the following error page …
Spring Boot Security - Default error page | MVP Java
Say hello to the built in error page. Not very helpful but better than a stack trace or no page at all.
We eventually need to map our custom error page to URI /error which is what Spring Boot Security is looking for by default.
STEP 4: We haven’t seen the logout page yet but you could go to the URL bar and type

Spring Boot Security - default logout page | MVP Java

STEP 5: If you click on the Logout button, the LogoutFilter will kick in and you will be redirected to the Login page once again.
If you had an existing Spring Web project and then added the Spring Security starter dependency afterwards, the whole application would  immediately be locked down. It’s secured by immediately implementing the default configuration we just covered. Obviously, that’s where we need to open things open – override default configuration.
Of course this is the end of the road for us since there is nothing else that this application really does. We have covered what Spring Boot Security offers, out of the box … but there is an extra gem (make sure you read the bonus section below)

Spring Boot Security Hidden Gem | Bonus

Default HttpFirewall | First line of defense

Spring Boot Security gives us a fully functional HTTP Firewall out of the box. This gem has gone mostly unnoticed and flies under the radar since it doesn’t generate any logging messages … hmmm .. sneaky!

Spring achieves this by including a HttpFirewall before any HTTP requests are sent through the security filter chain. The strict http firewall will reject any suspicious requests by throwing an exception.

How Does HttpFirewall Protect Us?

The Http firewall sanitizes and protects us against potentially harmfully crafted URLs, even before they reach the security filter chain. Some hackers can craft certain URLs in a manner which bypasses security constraints (wild stuff you never thought possible).

As an example, there are certain URLs that contain non-printable characters that can circumvent security like mvpjava.com where the “a” in the URL is actually a Unicode character like mvpj&#1072;va.com that looks like the English ASCII character “a” but is not … crazy stuff!

The HttpFirewall from Spring Security does lots more, check out my blog post on it here.