I have below three code snippets all doing the same thing: creating in-memory authentication. So how it impacts defining it in different method names?
- registerGlobal
- configure
- configureGlobal
- configureGlobalSecurity
First one:
public void registerGlobal(AuthenticationManagerBuilder auth) throws Exception { auth .inMemoryAuthentication() .withUser("user").password("password").roles("USER").and() .withUser("admin").password("password").roles("USER","ADMIN"); } }
Second one:
@Override protected void configure(AuthenticationManagerBuilder auth) throws Exception { auth .inMemoryAuthentication() .withUser("user").password("password").roles("USER"); }
Third one:
public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception { auth .inMemoryAuthentication() .withUser("user").password("password").roles("USER"); }
Fourth:
@Autowired public void configureGlobalSecurity(AuthenticationManagerBuilder auth) throws Exception { auth.inMemoryAuthentication().withUser("user").password("user").roles("USER"); }
UPDATE 1 : One more thing I would like to add:
configure() method is present in WebSecurityConfigurerAdapter class while others are not present.
UPDATE 2:
I renamed the method in my sample project to below and to my surprise it is working and authenticating the users.
you name it anything and it works
@Autowired public void anyMethodName(AuthenticationManagerBuilder auth) throws Exception { auth.inMemoryAuthentication().withUser("user").password("user").roles("USER"); }
Advertisement
Answer
In fact, you only have 2 different options.
Option 1: using annotations only (it cover your example 1, 3 and 4 – note that you didn’t include relevant annotations in your samples)
registerGlobal
, configureGlobal
, configureGlobalSecurity
are exact same way of doing things. You can name the method according your tastes. The only constraints are :
- annotate the method with
@Autowired
- the method MUST be in a class annotated with one of the following : @EnableWebSecurity, @EnableWebMvcSecurity, @EnableGlobalMethodSecurity, or @EnableGlobalAuthentication
- (and of course the method have an argument of type
AuthenticationManagerBuilder
)
(as you can see the name of the method is not important, that is why you found so many different method name when googling for code samples)
Here is an example of how it looks like :
@EnableWebSecurity public class MyConfiguration { @Autowired public void whatever(AuthenticationManagerBuilder auth) throws Exception { auth.inMemoryAuthentication() .withUser("user").password("password").roles("USER").and() .withUser("admin").password("password").roles("USER", "ADMIN"); } ... }
Option 2: using annotations + method overriding (it cover your example 2)
Overriding configure
is a convenient approach in a subclass of WebSecurityConfigurerAdapter
(or any @Configuration class implementing WebSecurityConfigurer
) but it have the same effect as the other option.
How to choose the correct approach?
It’s only a question of taste/programming-style because both approachs have the same effect.
The first option make sense when you want/need to keep your configuration in a single class, but your @Configuration class already extends some other class (and you don’t want to implement the whole WebSecurityConfigurer interface).
Let’s explain my last point in more details. Spring provides many Adapter classes that you can extends to speed up the development of your Spring configuration.
As an example, let’s take a commonly used Adapter : WebMvcConfigurerAdapter
. You will start with a very simple configuration like this :
@EnableWebMvc @Configuration @ComponentScan({ "com.company.mypackage" }) public class SpringWebConfig extends WebMvcConfigurerAdapter { }
What’s important here : your class already extends an Adapter class, so you can’t extends another one
Now, you need to add security configuration. You have the choice between including it in your existing SpringWebConfig
configuration class or create a new security specific configuration class. Here is a sample of both approaches:
1) Single @Configuration class approach
What’s important to note here : SpringWebConfig extends WebMvcConfigurerAdapter + @EnableWebSecurity
@EnableWebMvc @Configuration @ComponentScan({ "com.company.mypackage" }) @EnableWebSecurity public class SpringWebConfig extends WebMvcConfigurerAdapter { @Autowired public void whatever(AuthenticationManagerBuilder auth) throws Exception { auth.inMemoryAuthentication() .withUser("user").password("password").roles("USER").and() .withUser("admin").password("password").roles("USER", "ADMIN"); } }
2) Specific security @Configuration class
What’s important to note here : MySecurityConfig extends WebSecurityConfigurerAdapter
Keep your SpringWebConfig as it was and create a new @Configuration
class :
@Configuration @EnableWebSecurity public class MySecurityConfig extends WebSecurityConfigurerAdapter { @Overide public void configure(AuthenticationManagerBuilder auth) throws Exception { auth.inMemoryAuthentication() .withUser("user").password("password").roles("USER").and() .withUser("admin").password("password").roles("USER", "ADMIN"); } }