HttpSecurity, WebSecurity und AuthenticationManagerBuilder


Antworten:


125

configure (AuthenticationManagerBuilder) wird verwendet, um einen Authentifizierungsmechanismus einzurichten, indem AuthenticationProviders einfach hinzugefügt werden können: Beispiel: Im Folgenden wird die speicherinterne Authentifizierung mit den integrierten Anmeldungen "Benutzer" und "Administrator" definiert.

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

configure (HttpSecurity) ermöglicht die Konfiguration der webbasierten Sicherheit auf Ressourcenebene basierend auf einer Auswahlübereinstimmung. Beispiel: Das folgende Beispiel beschränkt die URLs, die mit / admin / beginnen, auf Benutzer mit ADMIN-Rolle und erklärt, dass andere URLs erforderlich sind erfolgreich authentifiziert.

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

configure (WebSecurity) wird für Konfigurationseinstellungen verwendet, die sich auf die globale Sicherheit auswirken (Ressourcen ignorieren, Debug-Modus festlegen, Anforderungen durch Implementierung einer benutzerdefinierten Firewall-Definition ablehnen). Die folgende Methode würde beispielsweise dazu führen, dass Anforderungen, die mit / resources / beginnen, zu Authentifizierungszwecken ignoriert werden.

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

Weitere Informationen finden Sie unter folgendem Link. Spring Security Java Config Preview: Web Security


2
Schöne Antwort Nick. Mit spring-security-config-5.0.3 (im Lieferumfang von spring-boot 2.0.0 enthalten) konnte ich die Methode nicht finden http.authorizeUrls(). Vielleicht wurde sie vor http.authorizeRequests()einiger Zeit umbenannt .
Yi Ou

5
Ich weiß, dass dies alt ist, aber was ist hier die beste Vorgehensweise? Ich habe Beispiele für Implementierungen der Methode configure (HttpSecurity http) gefunden, die http.antMatchers ("/ foo") aufrufen. PermitAll () ", was dem Aufrufen von web.ignoring (). AntMatchers (" / foo ") in configure (WebSecurity) entspricht Web) Methode.
Chrisinmtown

gute Antwort. Ich frage mich, ob wir jemals allowAll on HttpSecurity anrufen müssen. Können wir nicht einfach alle offenen URLs wie / register oder / login mit WebSecurity ignorieren? Warum verwenden dann alle Tutorials oder Antworten HttpSecurity.permitAll für / register und / login, aber WebSecurity.ingore für / publics of / resources? -
Mohd Waseem

3

Bei der allgemeinen Verwendung der WebSecurity- ignoring()Methode wird Spring Security weggelassen , und keine der Funktionen von Spring Security ist verfügbar. WebSecurity basiert auf 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();
}

Mit WebSecurity im obigen Beispiel kann Spring /resources/**und ignorieren /publics/**. Deshalb ist die .antMatchers("/publics/**").hasRole("USER")in HttpSecurity ist unbedacht .

Dadurch wird das Anforderungsmuster vollständig aus der Sicherheitsfilterkette entfernt. Beachten Sie, dass auf alles, was mit diesem Pfad übereinstimmt, keine Authentifizierungs- oder Autorisierungsdienste angewendet werden und frei zugänglich sind.

configure(HttpSecurity)Ermöglicht die Konfiguration der webbasierten Sicherheit auf Ressourcenebene basierend auf einer Auswahlübereinstimmung. Beispiel: Das folgende Beispiel beschränkt die URLs, die mit beginnen, /admin/auf Benutzer mit ADMIN-Rolle und erklärt, dass alle anderen URLs erfolgreich authentifiziert werden müssen.

configure(WebSecurity)wird für Konfigurationseinstellungen verwendet, die sich auf die globale Sicherheit auswirken (Ressourcen ignorieren, Debug-Modus festlegen, Anforderungen durch Implementierung einer benutzerdefinierten Firewall-Definition ablehnen). Die folgende Methode würde beispielsweise dazu führen, dass Anforderungen, die mit beginnen /resources/, für Authentifizierungszwecke ignoriert werden.

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

SecurityBuilder zum Erstellen eines AuthenticationManager. Ermöglicht das einfache Einbauen von Speicherauthentifizierung, LDAP-Authentifizierung, JDBC-basierter Authentifizierung, Hinzufügen von UserDetailsService und Hinzufügen von AuthenticationProvidern .

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

gute Antwort. Ich frage mich, ob wir jemals allowAll on HttpSecurity anrufen müssen. Können wir nicht einfach alle offenen URLs wie / register oder / login mit WebSecurity ignorieren? Warum verwenden dann alle Tutorials oder Antworten HttpSecurity.permitAll für / register und / login, aber WebSecurity.ingore für / publics of / resources?
Mohd Waseem
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.