HttpSecurity, WebSecurity e AuthenticationManagerBuilder


Risposte:


125

configure (AuthenticationManagerBuilder) viene utilizzato per stabilire un meccanismo di autenticazione consentendo di aggiungere facilmente AuthenticationProviders: ad es. Quanto segue definisce l'autenticazione in memoria con gli accessi "utente" e "admin" incorporati.

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

configure (HttpSecurity) consente la configurazione della sicurezza basata sul web a livello di risorsa, in base a una corrispondenza di selezione - ad esempio, l'esempio seguente limita gli URL che iniziano con / admin / agli utenti che hanno il ruolo ADMIN e dichiara che qualsiasi altro URL deve essere autenticato con successo.

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

configure (WebSecurity) viene utilizzato per le impostazioni di configurazione che influiscono sulla sicurezza globale (ignora le risorse, imposta la modalità di debug, rifiuta le richieste implementando una definizione firewall personalizzata). Ad esempio, il seguente metodo farebbe sì che qualsiasi richiesta che inizia con / resources / venga ignorata per scopi di autenticazione.

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

È possibile fare riferimento al seguente collegamento per ulteriori informazioni Spring Security Java Config Preview: Web Security


2
Bella risposta Nick. Con spring-security-config-5.0.3 (fornito con spring-boot 2.0.0), non sono riuscito a trovare il metodo http.authorizeUrls(), forse è stato rinominato http.authorizeRequests()qualche tempo fa.
Yi Ou

5
So che questo è vecchio, ma qual è la migliore pratica qui? Ho trovato esempi di implementazioni del metodo configure (HttpSecurity http) che invocano http.antMatchers ("/ foo"). AllowAll () "che sembra equivalente a invocare web.ignoring (). AntMatchers (" / foo ") nella configurazione (WebSecurity web).
chrisinmtown

Bella risposta. Mi chiedo se dovremo mai chiamare allowAll su HttpSecurity? Non possiamo semplicemente ignorare tutti gli URL aperti come / register o / login usando WebSecurity? Allora perché tutti i tutorial o le risposte usano HttpSecurity.permitAll per / register e / login ma WebSecurity.ingore per / publics of / resources? -
Mohd Waseem

3

L'uso generale del ignoring()metodo WebSecurity omette Spring Security e nessuna delle funzionalità di Spring Security sarà disponibile. WebSecurity si basa su 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 nell'esempio precedente consente a Spring di ignorare /resources/**e /publics/**. Pertanto l' .antMatchers("/publics/**").hasRole("USER")in HttpSecurity è unconsidered .

Ciò ometterà completamente il modello di richiesta dalla catena del filtro di sicurezza. Nota che qualsiasi cosa che corrisponde a questo percorso non avrà quindi alcun servizio di autenticazione o autorizzazione applicato e sarà liberamente accessibile.

configure(HttpSecurity)consente la configurazione della sicurezza basata sul Web a livello di risorsa , in base a una corrispondenza di selezione, ad es. L'esempio seguente limita gli URL che iniziano con /admin/agli utenti che hanno il ruolo ADMIN e dichiara che qualsiasi altro URL deve essere autenticato correttamente.

configure(WebSecurity)viene utilizzato per le impostazioni di configurazione che influiscono sulla sicurezza globale (ignora le risorse, imposta la modalità di debug, rifiuta le richieste implementando una definizione firewall personalizzata). Ad esempio, il seguente metodo farebbe sì che qualsiasi richiesta che inizia con /resources/venga ignorata per scopi di autenticazione .

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

SecurityBuilder utilizzato per creare un file AuthenticationManager. Consente di creare facilmente autenticazione in memoria, autenticazione LDAP, autenticazione basata su JDBC, aggiunta di UserDetailsService e aggiunta di AuthenticationProvider .

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

Bella risposta. Mi chiedo se dovremo mai chiamare allowAll su HttpSecurity? Non possiamo semplicemente ignorare tutti gli URL aperti come / register o / login usando WebSecurity? Allora perché tutti i tutorial o le risposte usano HttpSecurity.permitAll per / register e / login ma WebSecurity.ingore per / publics of / resources?
Mohd Waseem
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.