If you're working on a Spring Security (and especially an OAuth) implementation, definitely have a look at the Learn Spring Security course:
>> LEARN SPRING SECURITYMocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Get started with Spring and Spring Boot, through the Learn Spring course:
>> LEARN SPRINGExplore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely β and automatically β with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. Thatβs where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions β one for newcomers and one for experienced users. Youβll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
1. Introduction
This tutorial will focus on Login with Spring Security. Weβre going to build on top of the previous Spring MVC example, as thatβs a necessary part of setting up the web application along with the login mechanism.
Further reading:
Spring Security - Redirect to the Previous URL After Login
Two Login Pages with Spring Security
Spring Security Form Login
2. The Maven Dependencies
When working with Spring Boot, the spring-boot-starter-security starter will automatically include all dependencies, such as spring-security-core, spring-security-web, and spring-security-config among others:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
<version>2.3.3.RELEASE</version>
</dependency>
If we donβt use Spring Boot, please see the Spring Security with Maven article, which describes how to add all required dependencies. Both standard spring-security-web and spring-security-config will be required.
3. Spring Security Java Configuration
Letβs start by creating a Spring Security configuration class that creates a SecurityFilterChain bean.
By adding @EnableWebSecurity, we get Spring Security and MVC integration support:
@Configuration
@EnableWebSecurity
public class SecSecurityConfig {
@Bean
public InMemoryUserDetailsManager userDetailsService() {
// InMemoryUserDetailsManager (see below)
}
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
// http builder configurations for authorize requests and form login (see below)
}
}
In this example, we used in-memory authentication and defined three users.
Next weβll go through the elements we used to create the form login configuration.
Letβs start by building our Authentication Manager.
3.1. InMemoryUserDetailsManager
The Authentication Provider is backed by a simple, in-memory implementation, InMemoryUserDetailsManager. This is useful for rapid prototyping when a full persistence mechanism is not yet necessary:
@Bean
public InMemoryUserDetailsManager userDetailsService() {
UserDetails user1 = User.withUsername("user1")
.password(passwordEncoder().encode("user1Pass"))
.roles("USER")
.build();
UserDetails user2 = User.withUsername("user2")
.password(passwordEncoder().encode("user2Pass"))
.roles("USER")
.build();
UserDetails admin = User.withUsername("admin")
.password(passwordEncoder().encode("adminPass"))
.roles("ADMIN")
.build();
return new InMemoryUserDetailsManager(user1, user2, admin);
}
Here weβll configure three users with the username, password, and role hard-coded.
Starting with Spring 5, we also have to define a password encoder. In our example, weβll use the BCryptPasswordEncoder:
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
Next letβs configure the HttpSecurity.
3.2. Configuration to Authorize Requests
Weβll start by doing the necessary configurations to Authorize Requests.
Here weβre allowing anonymous access on /login so that users can authenticate. Weβll restrict /admin to ADMIN roles and securing everything else:
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http.csrf()
.disable()
.authorizeRequests()
.antMatchers("/admin/**")
.hasRole("ADMIN")
.antMatchers("/anonymous*")
.anonymous()
.antMatchers("/login*")
.permitAll()
.anyRequest()
.authenticated()
.and()
// ...
}
Note that the order of the antMatchers() elements is significant; the more specific rules need to come first, followed by the more general ones.
3.3. Configuration for Form Login
Next weβll extend the above configuration for form login and logout:
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
// ...
.and()
.formLogin()
.loginPage("/login.html")
.loginProcessingUrl("/perform_login")
.defaultSuccessUrl("/homepage.html", true)
.failureUrl("/login.html?error=true")
.failureHandler(authenticationFailureHandler())
.and()
.logout()
.logoutUrl("/perform_logout")
.deleteCookies("JSESSIONID")
.logoutSuccessHandler(logoutSuccessHandler());
return http.build();
}
- loginPage() β the custom login page
- loginProcessingUrl() β the URL to submit the username and password to
- defaultSuccessUrl() β the landing page after a successful login
- failureUrl() β the landing page after an unsuccessful login
- logoutUrl() β the custom logout
4. Add Spring Security to the Web Application
To use the above-defined Spring Security configuration, we need to attach it to the web application.
Weβll use the WebApplicationInitializer, so we donβt need to provide any web.xml:
public class AppInitializer implements WebApplicationInitializer {
@Override
public void onStartup(ServletContext sc) {
AnnotationConfigWebApplicationContext root = new AnnotationConfigWebApplicationContext();
root.register(SecSecurityConfig.class);
sc.addListener(new ContextLoaderListener(root));
sc.addFilter("securityFilter", new DelegatingFilterProxy("springSecurityFilterChain"))
.addMappingForUrlPatterns(null, false, "/*");
}
}
Note that this initializer isnβt necessary if weβre using a Spring Boot application. For more details on how the security configuration is loaded in Spring Boot, have a look at our article on Spring Boot security auto-configuration.
5. The Spring Security XML Configuration
Letβs also have a look at the corresponding XML configuration.
The overall project is using Java configuration, so we need to import the XML configuration file via a Java @Configuration class:
@Configuration
@ImportResource({ "classpath:webSecurityConfig.xml" })
public class SecSecurityConfig {
public SecSecurityConfig() {
super();
}
}
And the Spring Security XML Configuration, webSecurityConfig.xml:
<http use-expressions="true">
<intercept-url pattern="/login*" access="isAnonymous()" />
<intercept-url pattern="/**" access="isAuthenticated()"/>
<form-login login-page='/login.html'
default-target-url="/homepage.html"
authentication-failure-url="/login.html?error=true" />
<logout logout-success-url="/login.html" />
</http>
<authentication-manager>
<authentication-provider>
<user-service>
<user name="user1" password="user1Pass" authorities="ROLE_USER" />
</user-service>
<password-encoder ref="encoder" />
</authentication-provider>
</authentication-manager>
<beans:bean id="encoder"
class="org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder">
</beans:bean>
6. The web.xml
Before the introduction of Spring 4, we used to configure Spring Security in the web.xml; only an additional filter added to the standard Spring MVC web.xml:
<display-name>Spring Secured Application</display-name>
<!-- Spring MVC -->
<!-- ... -->
<!-- Spring Security -->
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
The filter β DelegatingFilterProxy β simply delegates to a Spring-managed bean β the FilterChainProxy β which itself is able to benefit from full Spring bean life-cycle management and such.
7. The Login Form
The login form page is going to be registered with Spring MVC using the straightforward mechanism to map views names to URLs. Furthermore, there is no need for an explicit controller in between:
registry.addViewController("/login.html");
This, of course, corresponds to the login.jsp:
<html>
<head></head>
<body>
<h1>Login</h1>
<form name='f' action="login" method='POST'>
<table>
<tr>
<td>User:</td>
<td><input type='text' name='username' value=''></td>
</tr>
<tr>
<td>Password:</td>
<td><input type='password' name='password' /></td>
</tr>
<tr>
<td><input name="submit" type="submit" value="submit" /></td>
</tr>
</table>
</form>
</body>
</html>
The Spring Login form has the following relevant artifacts:
- login β the URL where the form is POSTed to trigger the authentication process
- username β the username
- password β the password
8. Further Configuring Spring Login
We briefly discussed a few configurations of the login mechanism when we introduced the Spring Security Configuration above. Now letβs go into some greater detail.
One reason to override most of the defaults in Spring Security is to hide that the application is secured with Spring Security. We also want to minimize the information a potential attacker knows about the application.
Fully configured, the login element looks like this:
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http.formLogin()
.loginPage("/login.html")
.loginProcessingUrl("/perform_login")
.defaultSuccessUrl("/homepage.html",true)
.failureUrl("/login.html?error=true")
return http.build();
}
Or the corresponding XML configuration:
<form-login
login-page='/login.html'
login-processing-url="/perform_login"
default-target-url="/homepage.html"
authentication-failure-url="/login.html?error=true"
always-use-default-target="true"/>
8.1. The Login Page
Next weβll configure a custom login page using the loginPage() method:
http.formLogin()
.loginPage("/login.html")
Similarly, we can use the XML configuration:
login-page='/login.html'
If we donβt specify this, Spring Security will generate a very basic Login Form at the /login URL.
8.2. The POST URL for Login
The default URL where the Spring Login will POST to trigger the authentication process is /login, which used to be /j_spring_security_check before Spring Security 4.
We can use the loginProcessingUrl method to override this URL:
http.formLogin()
.loginProcessingUrl("/perform_login")
We can also use the XML configuration:
login-processing-url="/perform_login"
By overriding this default URL, weβre concealing that the application is actually secured with Spring Security. This information should not be available externally.
8.3. The Landing Page on Success
After successfully logging in, we will be redirected to a page that by default is the root of the web application.
We can override this via the defaultSuccessUrl() method:
http.formLogin()
.defaultSuccessUrl("/homepage.html")
Or with XML configuration:
default-target-url="/homepage.html"
If the always-use-default-target attribute is set to true, then the user is always redirected to this page. If that attribute is set to false, then the user will be redirected to the previous page they wanted to visit before being prompted to authenticate.
8.4. The Landing Page on Failure
Similar to the Login Page, the Login Failure Page is autogenerated by Spring Security at /login?error by default.
To override this, we can use the failureUrl() method:
http.formLogin()
.failureUrl("/login.html?error=true")
Or with XML:
authentication-failure-url="/login.html?error=true"
9. Conclusion
In this Spring Login Example, we configured a simple authentication process. We also discussed the Spring Security Login Form, the Security Configuration, and some of the more advanced customizations available.
When the project runs locally, the sample HTML can be accessed at:
http://localhost:8080/spring-security-mvc-login/login.html
