Save 37% on Spring in Action, Fifth Edition. Just enter code fccwalls into the discount code box at checkout at manning.com.

Securing Spring

Have you ever noticed that most people in television sitcoms don’t lock their doors? In the days of Leave it to Beaver, it wasn’t unusual for people to leave their doors unlocked. But it seems crazy that in a day when we’re concerned with privacy and security, we see television characters enabling unhindered access to their apartments and homes.

Information is probably the most valuable item we now have; crooks are looking for ways to steal our data and identities by sneaking into unsecured applications. As software developers, we must take steps to protect the information that resides in our applications. Whether it’s an email account protected with a username/password pair or a brokerage account protected with a trading PIN, security is a crucial aspect of most applications.

Enabling Spring Security

The first step in securing your Spring application is to add the Spring Boot security starter dependency to your build. In the project’s pom.xml file, add the following entry:

 
  
      org.springframework.boot
      spring-boot-starter-security
  
 

If you’re using Spring Tool Suite, then this is even easier. Right click on the pom.xml file and select “Edit Starters” from the “Spring” context menu. The starter dependencies dialog appears. Select the “Security” entry under the “Core” category as shown in figure 1.

Figure 1. Adding the security starter with Spring Tool Suite.

Believe it or not, that dependency is the only thing which is required to secure an application. When the application starts, auto-configuration detects that Spring Security is in the classpath and sets up some basic security configuration.

If you want to try it out, fire up the application and try to visit the home page (or any page for that matter). You’ll be prompted for authentication with an HTTP Basic authentication dialog box. To get past it, you’ll need to provide a username and password. The username is “user”. As for the password, it’s randomly generated and written to the application’s log file. The log entry looks something like this:

 
 Using default security password: 087cfc6a-027d-44bc-95d7-cbb3a798a1ea
 

Assuming you enter the username and password correctly, you’ll be granted access to the application.

It seems that securing Spring applications is easy work. Now that I have secured my precious Taco Cloud application, I suppose I could end this article, but before we get ahead of ourselves, let’s consider what kind of security autoconfiguration provides us.

By doing nothing more than adding the security starter to the project’s build, we get the following security features:

• All HTTP request paths require authentication.
• No specific roles or authorities are required.
• No login page exists.
• Authentication’s prompted with HTTP Basic authentication.
• Only one user exists; the username is “user”.

Although this seems to be a good start, I’d think that the security needs of most applications (Taco Cloud included) are quite different from these rudimentary security features.

I guess we have more work to do if we’re going to properly secure the Taco Cloud application. We’ll need to at least configure Spring Security to:

• prompt for authentication with a login page, instead of an HTTP Basic dialog box
• provide for multiple users, along with a registration page for new Taco Cloud customers to sign up
• apply different security rules for different request paths (the home page and registration pages, for example, shouldn’t require authentication at all)

To achieve our security needs for Taco Cloud, we’re going to need to write some explicit configuration, overriding what auto-configuration has given us. The next step would be to start with configuring a proper user store to allow more than one user, but that’s a topic for another time.

If you’re interested in learning more about the book, check it out on liveBook here. Also see this slide deck for more info.