HttpSecurity, WebSecurity i AuthenticationManagerBuilder


Odpowiedzi:


125

configure (AuthenticationManagerBuilder) służy do ustanowienia mechanizmu uwierzytelniania poprzez umożliwienie łatwego dodawania AuthenticationProviderów: np. Poniżej zdefiniowano uwierzytelnianie w pamięci z wbudowanymi loginami „użytkownik” i „administrator”.

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

configure (HttpSecurity) umożliwia konfigurację zabezpieczeń internetowych na poziomie zasobów w oparciu o dopasowanie wyboru - np. poniższy przykład ogranicza adresy URL zaczynające się od / admin / do użytkowników, którzy mają rolę ADMINISTRATOR, i deklaruje, że wszelkie inne adresy URL muszą być pomyślnie uwierzytelniony.

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

configure (WebSecurity) jest używany do ustawień konfiguracji, które mają wpływ na globalne bezpieczeństwo (ignorowanie zasobów, ustawianie trybu debugowania, odrzucanie żądań poprzez implementację niestandardowej definicji zapory). Na przykład poniższa metoda spowodowałaby, że każde żądanie zaczynające się od / resources / zostało zignorowane na potrzeby uwierzytelniania.

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

Możesz skorzystać z następującego łącza, aby uzyskać więcej informacji Spring Security Java Config Preview: Web Security


2
Dobra odpowiedź, Nick. W przypadku spring-security-config-5.0.3 (który jest dostarczany z spring-boot 2.0.0) nie mogłem znaleźć metody http.authorizeUrls(), być może została zmieniona na http.authorizeRequests()jakiś czas temu.
Yi Ou,

5
Wiem, że to stare, ale jaka jest najlepsza praktyka tutaj? Znalazłem przykłady implementacji metod configure (HttpSecurity http) wywołujących http.antMatchers ("/ foo"). AllowAll () ", co wydaje się równoważne wywołaniu web.ignoring (). AntMatchers (" / foo ") w konfiguracji (WebSecurity web)
chrisinmtown

świetna odpowiedź. Zastanawiam się, czy kiedykolwiek będziemy musieli zadzwonić do allowAll w HttpSecurity? Czy nie możemy po prostu zignorować wszystkich otwartych adresów URL, takich jak / register lub / login przy użyciu WebSecurity? Dlaczego więc wszystkie samouczki lub odpowiedzi używają HttpSecurity.permitAll dla / register i / login, ale WebSecurity.ingore dla / publics of / resources? -
Mohd Waseem

3

Ogólne użycie ignoring()metody WebSecurity pomija Spring Security i żadna z funkcji Spring Security nie będzie dostępna. WebSecurity jest oparte na 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 w powyższym przykładzie pozwala Springowi ignorować /resources/**i /publics/**. Dlatego .antMatchers("/publics/**").hasRole("USER")w HttpSecurity nie jest brane pod uwagę .

Spowoduje to całkowite pominięcie wzorca żądania z łańcucha filtrów bezpieczeństwa. Zwróć uwagę, że wszystko, co pasuje do tej ścieżki, nie będzie wówczas miało zastosowania usług uwierzytelniania ani autoryzacji i będzie swobodnie dostępne.

configure(HttpSecurity)umożliwia konfigurację zabezpieczeń internetowych na poziomie zasobów w oparciu o dopasowanie wyboru - np. poniższy przykład ogranicza adresy URL zaczynające się od /admin/do użytkowników posiadających rolę ADMINISTRATOR i deklaruje, że wszelkie inne adresy URL muszą zostać pomyślnie uwierzytelnione.

configure(WebSecurity)służy do konfigurowania ustawień, które mają wpływ na globalne bezpieczeństwo (ignorowanie zasobów, ustawianie trybu debugowania, odrzucanie żądań poprzez implementację niestandardowej definicji zapory). Na przykład poniższa metoda spowodowałaby, że każde żądanie rozpoczynające się /resources/od zostanie zignorowane na potrzeby uwierzytelniania .

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

SecurityBuilder używany do tworzenia AuthenticationManager. Umożliwia łatwe budowanie uwierzytelniania pamięci, uwierzytelniania LDAP, uwierzytelniania opartego na JDBC, dodawania usługi UserDetailsService i dodawania usługi AuthenticationProvider .

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

świetna odpowiedź. Zastanawiam się, czy kiedykolwiek będziemy musieli zadzwonić do allowAll w HttpSecurity? Czy nie możemy po prostu zignorować wszystkich otwartych adresów URL, takich jak / register lub / login przy użyciu WebSecurity? Dlaczego więc wszystkie samouczki lub odpowiedzi używają HttpSecurity.permitAll dla / register i / login, ale WebSecurity.ingore dla / publics of / resources?
Mohd Waseem
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.