Skip to content
Advertisement

Difference between registerGlobal(), configure(), configureGlobal(),configureGlobalSecurity in Spring security

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?

  1. registerGlobal
  2. configure
  3. configureGlobal
  4. 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 :

(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");
    }
}
User contributions licensed under: CC BY-SA
1 People found this is helpful
Advertisement