If you define a @Configuration with @EnableWebSecurity anywhere in your application, it switches off the default webapp security settings in Spring Boot (but leaves the Actuator’s security enabled). To tweak the defaults try setting properties in security.* (see SecurityProperties for details of available settings) and the SECURITY section of “Common Application Properties”.

If you provide a @Bean of type AuthenticationManager, the default one is not created, so you have the full feature set of Spring Security available (such as various authentication options).

Spring Security also provides a convenient AuthenticationManagerBuilder, which can be used to build an AuthenticationManager with common options. The recommended way to use this in a webapp is to inject it into a void method in a WebSecurityConfigurerAdapter, as shown in the following example:

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

	@Autowired
	public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception {
			auth.inMemoryAuthentication()
				.withUser("barry").password("password").roles("USER"); // ... etc.
	}

	// ... other stuff for application security

}

You get the best results if you put this in a nested class or a standalone class (that is, not mixed in with a lot of other @Beans that might be allowed to influence the order of instantiation). The secure web sample is a useful template to follow.

If you experience instantiation issues (for example, when using JDBC or JPA for the user detail store), it might be worth extracting the AuthenticationManagerBuilder callback into a GlobalAuthenticationConfigurerAdapter (in the init() method so that it happens before the authentication manager is needed elsewhere), as shown in the following example:

@Configuration
public class AuthenticationManagerConfiguration extends
		GlobalAuthenticationConfigurerAdapter {

	@Override
	public void init(AuthenticationManagerBuilder auth) {
		auth.inMemoryAuthentication() // ... etc.
	}

}

Ensuring that all your main endpoints are only available over HTTPS is an important chore for any application. If you use Tomcat as a servlet container, then Spring Boot adds Tomcat’s own RemoteIpValve automatically if it detects some environment settings, and you should be able to rely on the HttpServletRequest to report whether it is secure or not (even downstream of a proxy server that handles the real SSL termination). The standard behavior is determined by the presence or absence of certain request headers (x-forwarded-for and x-forwarded-proto), whose names are conventional, so it should work with most front-end proxies. You can switch on the valve by adding some entries to application.properties, as shown in the following example:

server.tomcat.remote-ip-header=x-forwarded-for
server.tomcat.protocol-header=x-forwarded-proto

(The presence of either of those properties switches on the valve. Alternatively, you can add the RemoteIpValve yourself by adding a TomcatServletWebServerFactory bean.)

Spring Security can also be configured to require a secure channel for all (or some) requests. To switch that on in a Spring Boot application, set security.require_ssl to true in application.properties.