HttpSecurity, WebSecurity e AuthenticationManagerBuilder


Respostas:


125

configure (AuthenticationManagerBuilder) é usado para estabelecer um mecanismo de autenticação, permitindo que AuthenticationProviders sejam adicionados facilmente: por exemplo, o seguinte define a autenticação na memória com os logins embutidos de 'usuário' e 'admin'.

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

configure (HttpSecurity) permite a configuração de segurança baseada na web em um nível de recurso, com base em uma combinação de seleção - por exemplo, o exemplo abaixo restringe os URLs que começam com / admin / para usuários que têm função ADMIN e declara que quaisquer outros URLs precisam ser autenticado com sucesso.

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

configure (WebSecurity) é usado para configurações que impactam a segurança global (ignorar recursos, definir modo de depuração, rejeitar solicitações implementando uma definição de firewall personalizada). Por exemplo, o método a seguir faria com que qualquer solicitação que comece com / resources / fosse ignorada para fins de autenticação.

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

Você pode consultar o link a seguir para obter mais informações Spring Security Java Config Preview: Web Security


2
Boa resposta, Nick. Com o spring-security-config-5.0.3 (que vem com o spring-boot 2.0.0), não consegui encontrar o método http.authorizeUrls(), talvez ele tenha sido renomeado para http.authorizeRequests()algum tempo atrás.
Yi Ou

5
Eu sei que isso é antigo, mas qual é a melhor prática aqui? Encontrei exemplos de implementações do método configure (HttpSecurity http) invocando http.antMatchers ("/ foo"). PermitAll () "que parece equivalente a invocar web.ignoring (). AntMatchers (" / foo ") no configure (WebSecurity método web).
chrisinmtown

Ótima resposta. Estou me perguntando se algum dia precisaremos chamar permitAll em HttpSecurity? Não podemos simplesmente ignorar todos os urls abertos como / register ou / login usando WebSecurity? Então, por que todos os tutoriais ou respostas usam HttpSecurity.permitAll para / register e / login, mas WebSecurity.ingore para / publics de / resources? -
Mohd Waseem

3

O uso geral do ignoring()método WebSecurity omite o Spring Security e nenhum dos recursos do Spring Security estará disponível. WebSecurity é baseado em 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 no exemplo acima permite que o Spring ignore /resources/**e /publics/**. Portanto, o .antMatchers("/publics/**").hasRole("USER")em HttpSecurity não é considerado .

Isso omitirá inteiramente o padrão de solicitação da cadeia de filtros de segurança. Observe que qualquer coisa que corresponda a este caminho não terá serviços de autenticação ou autorização aplicados e estará acessível gratuitamente.

configure(HttpSecurity)permite a configuração de segurança baseada na web em um nível de recurso , com base em uma correspondência de seleção - por exemplo, O exemplo abaixo restringe os URLs que começam com /admin/para usuários que têm função ADMIN e declara que quaisquer outros URLs precisam ser autenticados com sucesso.

configure(WebSecurity)é usado para definições de configuração que afetam a segurança global (ignorar recursos, definir modo de depuração, rejeitar solicitações implementando uma definição de firewall personalizada). Por exemplo, o método a seguir faria com que qualquer solicitação iniciada com /resources/seja ignorada para fins de autenticação .

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

SecurityBuilder usado para criar um AuthenticationManager. Permite criar facilmente autenticação de memória, autenticação LDAP, autenticação baseada em JDBC, adicionando UserDetailsService e adicionando AuthenticationProvider's .

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

Ótima resposta. Estou me perguntando se algum dia precisaremos chamar permitAll em HttpSecurity? Não podemos simplesmente ignorar todos os urls abertos como / register ou / login usando WebSecurity? Então, por que todos os tutoriais ou respostas usam HttpSecurity.permitAll para / register e / login, mas WebSecurity.ingore para / publics de / resources?
Mohd Waseem
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.