Spring Boot Fundamentals

Security with Spring Boot

Your browser needs to be JavaScript capable to view this video

Try reloading this page, or reviewing your browser settings

This segment explains Spring Security and how Spring Boot helps to auto-configure security with ease.

Keywords

  • security
  • spring boot
  • basic authentication
  • form login
  • secure

About this video

Author(s)
Felipe Gutierrez
First online
22 May 2021
DOI
https://doi.org/10.1007/978-1-4842-7066-0_23
Online ISBN
978-1-4842-7066-0
Publisher
Apress
Copyright information
© Felipe Gutierrez 2021

Video Transcript

Hello and welcome back. Let’s start with security with Spring Boot. Spring Boot uses the spring-security project to simplify the protection of applications. To create secure Spring Boot apps, you need to add the spring-boot-starter-security. And of course, Spring Boot will auto-configure the security.

By default, it’s going to create a default password, meaning that when you start your application, if you have the security dependency, it’s going to create a random password that is going to be print out in the console. Again, this is without adding any extra configuration, just by adding this particular dependency. Spring Security will provide more secure defaults and the ability to migrate how password are stored, and in this case, is going to provide the password encoded, and will delegate to a password encoder a delegated class, and is going to use one of the algorithms that you provide by default. It’s going to use the BCrypt.

Now, Spring Boot– in order to actually change these defaults, the only thing that we need to provide is a UserDetailsService. So here, you can plug in whatever security your company or you want to apply. So in this case, if you want to use any SAML technology or, for example, SiteMinder, or maybe some OAuth kind of a security, you can– the only thing that you need to do is just to provide the UserDetailsService.

And in this case, in this particular example, we’re using in-memory, so you need to see that we are creating an instance that says InMemoryUserDetailsManager, where we are passing the username, the password, and the role, right? And we are using the default password encoder. You can use anything different, right? So you can use that. Again, the only thing that you need to return back will be the UserDetailsService instance. That will be a part of the trick of the Spring Security.

Now, if you want to configure more in-depth Spring Security, the only thing is that you need to extend the WebSecurityConfigurerAdapter class. So in this case, you can all write only the methods that you want to provide. If in this example we have a configurer where you pass a authentication manager build– and in this case, we’re using in-memory authentication– again, here, we’re not using the UserDetailsService.

We are going, and we are trying to plug in a simple security here, where we are telling these guys in memory with these particular roles and with this particular password encoder. Also, if you want to secure some of your endpoints, you need to overwrite also the configurer that accepts the HTTP security, where you can say any request should be fully authenticated and just do an HTTP basic security.

Now, you can use JDBC, again, just by extending the WebSecurityConfigurerAdapter. And something that you need to see is that you are creating that JdbcUserDetailsManager. Remember that? Remember that we need to provide the UserDetailsService, so this is how if you want to use the JDBC. So there are many options that you can use in order to provide security.

Now, with the Spring Boot Security and using all the properties, you can use the server.ssl properties in order to configure everything, right? On the Spring Boot Actuator will require the ACTUATOR role, and of course, the Spring Boot Security provides several utility classes that can be used with a request matcher, like in the example, right?

So for example, we have, if you already put the actuator– something that we’re going to see in the next segment– you have the EndpointRequest to “/health,” meaning that every single endpoint that ends with /health, you’re going to be allowed. Normally, this is going to be useful where you have, maybe, load balancers that are checking the health of your server to see if it’s up, so you can permit everything as a public resource, for example. And any other endpoint that has the role ACTUATOR can actually be accessed by that particular user that has that role.

And of course, you have the StaticResourceRequest to common locations, meaning that, if you have CSS, if you have images or JavaScript that you– they’ll need to be secure because it’s part of the application, of course, you can do that as well by doing permitAll. And then, you can have the ad requestMatchers, where it says only the user that has the role USER can visualize these inputs or can have access to these resources. And of course, we have an httpBasic. So we’re going to get into the Spring Boot demo to do security and then come back for the summary.