HttpSecurity, WebSecurity y AuthenticationManagerBuilder

100

¿Alguien podría explicar cuándo anular configure(HttpSecurity), configure(WebSecurity)y configure(AuthenticationManagerBuilder)?

— usuario3488241
fuente

125

configure (AuthenticationManagerBuilder) se utiliza para establecer un mecanismo de autenticación al permitir que AuthenticationProviders se agreguen fácilmente: por ejemplo, lo siguiente define la autenticación en memoria con los inicios de sesión de 'usuario' y 'administrador' incorporados.

public void configure(AuthenticationManagerBuilder auth) {
    auth
        .inMemoryAuthentication()
        .withUser("user")
        .password("password")
        .roles("USER")
    .and()
        .withUser("admin")
        .password("password")
        .roles("ADMIN","USER");
}

configure (HttpSecurity) permite la configuración de la seguridad basada en web a nivel de recursos, en función de una coincidencia de selección, por ejemplo, el ejemplo siguiente restringe las URL que comienzan con / admin / a los usuarios que tienen el rol ADMIN y declara que cualquier otra URL debe ser autenticado correctamente.

protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
        .antMatchers("/admin/**").hasRole("ADMIN")
        .anyRequest().authenticated()
}

configure (WebSecurity) se utiliza para las opciones de configuración que afectan la seguridad global (ignorar recursos, establecer el modo de depuración, rechazar solicitudes mediante la implementación de una definición de firewall personalizada). Por ejemplo, el siguiente método haría que cualquier solicitud que comience con / resources / se ignore para fines de autenticación.

public void configure(WebSecurity web) throws Exception {
    web
        .ignoring()
        .antMatchers("/resources/**");
}

Puede consultar el siguiente enlace para obtener más información Spring Security Java Config Preview: Web Security

— Nick Vasic
fuente

2

Buena respuesta Nick. Con spring-security-config-5.0.3 (que viene con spring-boot 2.0.0), no pude encontrar el método http.authorizeUrls(), tal vez se le cambió el nombre a hace http.authorizeRequests()algún tiempo.

— Yi Ou

5

Sé que esto es antiguo, pero ¿cuál es la mejor práctica aquí? He encontrado ejemplos de implementaciones del método configure (HttpSecurity http) que invocan http.antMatchers ("/ foo"). PermitAll () "que parece equivalente a invocar web.ignoring (). AntMatchers (" / foo ") en la configuración (WebSecurity web) método.

— chrisinmtown

gran respuesta. Me pregunto si alguna vez necesitamos llamar a permitAll en HttpSecurity. ¿No podemos simplemente ignorar todas las URL abiertas como / register o / login usando WebSecurity? Entonces, ¿por qué todos los tutoriales o respuestas usan HttpSecurity.permitAll para / register y / login pero WebSecurity.ingore para / publics of / resources? -

— Mohd Waseem

3

El uso general del ignoring()método WebSecurity omite Spring Security y ninguna de las funciones de Spring Security estará disponible. WebSecurity se basa por encima de HttpSecurity.

@Override
public void configure(WebSecurity web) throws Exception {
    web
        .ignoring()
        .antMatchers("/resources/**")
        .antMatchers("/publics/**");
}

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
        .antMatchers("/admin/**").hasRole("ADMIN")
        .antMatchers("/publics/**").hasRole("USER") // no effect
        .anyRequest().authenticated();
}

WebSecurity en el ejemplo anterior permite que Spring ignore /resources/**y /publics/**. Por lo tanto, .antMatchers("/publics/**").hasRole("USER")no se considera en HttpSecurity .

Esto omitirá por completo el patrón de solicitud de la cadena de filtros de seguridad. Tenga en cuenta que cualquier cosa que coincida con esta ruta no tendrá servicios de autenticación o autorización aplicados y será de libre acceso.

configure(HttpSecurity)permite la configuración de la seguridad basada en web a nivel de recursos , basándose en una coincidencia de selección, por ejemplo, el ejemplo siguiente restringe las URL que comienzan con /admin/a los usuarios que tienen la función ADMIN y declara que cualquier otra URL debe autenticarse correctamente.

configure(WebSecurity)se utiliza para las opciones de configuración que afectan la seguridad global (ignorar recursos, establecer el modo de depuración, rechazar solicitudes mediante la implementación de una definición de firewall personalizada). Por ejemplo, el siguiente método haría que /resources/se ignorara cualquier solicitud que comience con para fines de autenticación .

AuthenticationManagerBuilder
extends AbstractConfiguredSecurityBuilder<AuthenticationManager,AuthenticationManagerBuilder>
implements ProviderManagerBuilder<AuthenticationManagerBuilder>

SecurityBuilder utilizado para crear un AuthenticationManager. Permite crear fácilmente autenticación de memoria, autenticación LDAP, autenticación basada en JDBC, agregar UserDetailsService y agregar AuthenticationProvider .

@Override
     protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.inMemoryAuthentication().withUser("user").password("password").roles("USER"); 
        auth.userDetailsService(customUserDetailService).passwordEncoder(new BCryptPasswordEncoder());
     }

— Patel Romil
fuente

gran respuesta. Me pregunto si alguna vez necesitamos llamar a permitAll en HttpSecurity. ¿No podemos simplemente ignorar todas las URL abiertas como / register o / login usando WebSecurity? Entonces, ¿por qué todos los tutoriales o respuestas usan HttpSecurity.permitAll para / register y / login pero WebSecurity.ingore para / publics of / resources?

— Mohd Waseem