HttpSecurity, WebSecurity và AuthenticationManagerBuilder


Câu trả lời:


125

config (AuthenticationManagerBuilder) được sử dụng để thiết lập cơ chế xác thực bằng cách cho phép dễ dàng thêm AuthenticationProviders: ví dụ: Phần sau định nghĩa xác thực trong bộ nhớ với thông tin đăng nhập 'người dùng' và 'quản trị viên' được tích hợp sẵn.

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

cấu hình (HttpSecurity) cho phép cấu hình bảo mật dựa trên web ở cấp tài nguyên, dựa trên kết hợp lựa chọn - ví dụ: Ví dụ dưới đây hạn chế các URL bắt đầu bằng / admin / đối với người dùng có vai trò QUẢN TRỊ và tuyên bố rằng bất kỳ URL nào khác cần phải đã xác thực thành công.

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

config (WebSecurity) được sử dụng cho các cài đặt cấu hình ảnh hưởng đến bảo mật toàn cầu (bỏ qua tài nguyên, đặt chế độ gỡ lỗi, từ chối yêu cầu bằng cách triển khai định nghĩa tường lửa tùy chỉnh). Ví dụ: phương pháp sau sẽ khiến bất kỳ yêu cầu nào bắt đầu bằng / resources / bị bỏ qua cho mục đích xác thực.

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

Bạn có thể tham khảo liên kết sau để biết thêm thông tin Spring Security Java Config Preview: Web Security


2
Câu trả lời hay đấy Nick. Với spring-security-config-5.0.3 (đi kèm với spring-boot 2.0.0), tôi không thể tìm thấy phương pháp http.authorizeUrls(), có thể nó đã được đổi tên thành http.authorizeRequests()cách đây không lâu.
Yi Ou

5
Tôi biết điều này đã cũ, nhưng cách tốt nhất ở đây là gì? Tôi đã tìm thấy các ví dụ về triển khai phương thức config (HttpSecurity http) gọi http.antMatchers ("/ foo"). AllowAll () "có vẻ tương đương với việc gọi web.ignoring (). AntMatchers (" / foo ") trong cấu hình (WebSecurity web) phương pháp.
chrisinmtown

câu trả lời chính xác. Tôi đang tự hỏi liệu chúng ta có bao giờ cần gọi allowAll trên HttpSecurity không? Chúng ta không thể bỏ qua tất cả các url đang mở như / đăng ký hoặc / đăng nhập bằng cách sử dụng WebSecurity? Vậy tại sao tất cả các hướng dẫn hoặc câu trả lời đều sử dụng HttpSecurity.permitAll cho / đăng ký và / đăng nhập nhưng lại sử dụng WebSecurity.ingore cho / publics of / resources? -
Mohd Waseem

3

Việc sử dụng chung ignoring()phương pháp WebSecurity bỏ qua Spring Security và không có tính năng nào của Spring Security sẽ khả dụng. WebSecurity dựa trên 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 trong ví dụ trên cho phép Spring bỏ qua /resources/**/publics/**. Do đó, .antMatchers("/publics/**").hasRole("USER")trong HttpSecurity là unconsidered .

Điều này sẽ loại bỏ hoàn toàn mẫu yêu cầu khỏi chuỗi bộ lọc bảo mật. Lưu ý rằng bất kỳ thứ gì khớp với đường dẫn này sau đó sẽ không có dịch vụ xác thực hoặc ủy quyền được áp dụng và sẽ có thể truy cập miễn phí.

configure(HttpSecurity)cho phép cấu hình bảo mật dựa trên web ở cấp tài nguyên , dựa trên kết quả phù hợp lựa chọn - ví dụ: Ví dụ dưới đây hạn chế các URL bắt đầu với /admin/người dùng có vai trò QUẢN TRỊ và tuyên bố rằng bất kỳ URL nào khác cần được xác thực thành công.

configure(WebSecurity)được sử dụng cho các cài đặt cấu hình ảnh hưởng đến bảo mật toàn cầu (bỏ qua tài nguyên, đặt chế độ gỡ lỗi, từ chối yêu cầu bằng cách triển khai định nghĩa tường lửa tùy chỉnh). Ví dụ: phương pháp sau sẽ khiến mọi yêu cầu bắt đầu bằng /resources/bị bỏ qua cho mục đích xác thực .

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

SecurityBuilder được sử dụng để tạo AuthenticationManager. Cho phép dễ dàng xây dựng trong xác thực bộ nhớ, xác thực LDAP, xác thực dựa trên JDBC, thêm UserDetailsService và thêm AuthenticationProvider's .

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

câu trả lời chính xác. Tôi đang tự hỏi liệu chúng ta có bao giờ cần gọi allowAll trên HttpSecurity không? Chúng ta không thể bỏ qua tất cả các url đang mở như / đăng ký hoặc / đăng nhập bằng cách sử dụng WebSecurity? Vậy tại sao tất cả các hướng dẫn hoặc câu trả lời đều sử dụng HttpSecurity.permitAll cho / đăng ký và / đăng nhập nhưng lại sử dụng WebSecurity.ingore cho / publics of / resources?
Mohd Waseem
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.