Episode 3 #
Ok, we have now some routes, and we need to secure them. We’ll use Spring Security and Basic Authentication.
General architecture #
A “Bird Eye” view of where the security is located:
A detailed look at Spring Security‘s architecture: https://dzone.com/articles/spring-security-authentication.
The complete documentation: https://docs.spring.io/spring-security/site/docs/current/reference/html5/
This to read in particular:
- Introduction, all of it.
- Servlet Applications
- FYI: servlet is a server applet SERV-er app-LET.
- server being the physical or virtual computer.
- applet is the application that runs on a server.
- Chapters 8-11, 16,
- FYI: servlet is a server applet SERV-er app-LET.
In Memory #
Our code will be based on the Securing Web article.
The main difference from the article and our code will consist in using .httpBasic()
instead of .formLogin()
We will secure only the APIs, we’ll not create a html page for that. If you want, feel free to do the guide as described as exercise for you.
Code Demo #
Here’s the example of this repository: Feature/security basic in memory
Demo’s bullet points #
The central parts of this exercise are:
pom.xml
, added security starter dependency.spring-boot-starter-security
WebSecurityConfig
, created a dedicated config class.@Configuration
, annotatedWebSecurityConfig
to declare it as configuration class.@EnableWebSecurity
, annotatedWebSecurityConfig
to enable features fromsecurity starter
.WebSecurityConfigurerAdapter
,WebSecurityConfig
has to extend the adapter in order to be able to override default settings.configure(HttpSecurity http)
, override the configuration of thehttp
pipe.configure(WebSecurity web)
, override the configuration of theweb
pipe to ignoreOPTIONS
.- Preflight request : https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
UserDetailsService userDetailsService()
created custom user details service by using the in memory implementation from the security starterInMemoryUserDetailsManager
- The users present in this piece of java code are your actual users for the API.
Please mind that this method is rarely used in production. I mean I never saw it, yet I’m sure there might be some particular use cases for that.
In Database #
Let’s go a bit more real this time. We’ll connect our authentication logic to users located in your database.
Code Demo #
Here’s the example of this repository: Feature/security basic in db
Demo’s bullet points #
The central parts are the ones described above plus a bunch of new ones:
liquibase
scripts to create theUSERS
table and put 3 demo users, the password will be hashed inMD5
by default/users
, feature to manageUser entity
andrepository
- a custom
UserDetailsService
capable of finding users in db PasswordChecker
interface andMD5Checker
implementation to check the user password- a custom
AuthenticationProvider
capable of checking the passwords and creating aUserDetails
object - properties to activate
IN_MEMORY
orDB
storage, so that we can have this distinction SecurityProperties
to have the properties injectable- This particular class will not use
lombok
becausespring-boot-configuration-processor
cannot handlelombok
- This particular class will not use
In all the source code we’ll have all kind of hints and links to the articles that talk about that particular matter. Feel free to read the articles and practice them.