HttpSecurity, WebSecurity et AuthenticationManagerBuilder


Réponses:


125

configure (AuthenticationManagerBuilder) est utilisé pour établir un mécanisme d'authentification en permettant aux AuthenticationProviders d'être ajoutés facilement: par exemple, ce qui suit définit l'authentification en mémoire avec les connexions intégrées «utilisateur» et «admin».

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

configure (HttpSecurity) permet la configuration de la sécurité basée sur le Web au niveau des ressources, en fonction d'une correspondance de sélection - par exemple, l'exemple ci-dessous limite les URL commençant par / admin / aux utilisateurs qui ont le rôle ADMIN, et déclare que toutes les autres URL doivent être authentifié avec succès.

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

configure (WebSecurity) est utilisé pour les paramètres de configuration qui ont un impact sur la sécurité globale (ignorer les ressources, définir le mode de débogage, rejeter les demandes en implémentant une définition de pare-feu personnalisée). Par exemple, la méthode suivante ferait en sorte que toute demande commençant par / resources / soit ignorée à des fins d'authentification.

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

Vous pouvez vous référer au lien suivant pour plus d'informations Spring Security Java Config Preview: Sécurité Web


2
Belle réponse Nick. Avec spring-security-config-5.0.3 (qui est livré avec spring-boot 2.0.0), je n'ai pas trouvé la méthode http.authorizeUrls(), peut-être qu'elle a été renommée il y a http.authorizeRequests()quelque temps.
Yi Ou

5
Je sais que c'est vieux, mais quelle est la meilleure pratique ici? J'ai trouvé des exemples d'implémentations de méthode configure (HttpSecurity http) appelant http.antMatchers ("/ foo"). PermitAll () "qui semble équivalent à invoquer web.ignoring (). AntMatchers (" / foo ") dans le configure (WebSecurity web) méthode.
chrisinmtown

très bonne réponse. Je me demande si nous devons appeler permitAll sur HttpSecurity? Ne pouvons-nous pas simplement ignorer toutes les URL ouvertes comme / register ou / login en utilisant WebSecurity? Alors pourquoi tous les didacticiels ou réponses utilisent HttpSecurity.permitAll pour / register et / login mais WebSecurity.ingore pour / publics of / resources? -
Mohd Waseem le

3

L'utilisation générale de la ignoring()méthode WebSecurity omet Spring Security et aucune des fonctionnalités de Spring Security ne sera disponible. WebSecurity est basé sur 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 dans l'exemple ci-dessus permet à Spring d'ignorer /resources/**et /publics/**. Par conséquent, le .antMatchers("/publics/**").hasRole("USER")dans HttpSecurity n'est pas pris en compte .

Cela omettra complètement le modèle de demande de la chaîne de filtres de sécurité. Notez que tout ce qui correspond à ce chemin n'aura alors aucun service d'authentification ou d'autorisation appliqué et sera librement accessible.

configure(HttpSecurity)permet la configuration de la sécurité Web au niveau des ressources , en fonction d'une correspondance de sélection - par exemple, l'exemple ci-dessous restreint les URL commençant par /admin/aux utilisateurs qui ont le rôle ADMIN et déclare que toutes les autres URL doivent être authentifiées avec succès.

configure(WebSecurity)est utilisé pour les paramètres de configuration qui ont un impact sur la sécurité globale (ignorer les ressources, définir le mode de débogage, rejeter les demandes en implémentant une définition de pare-feu personnalisée). Par exemple, la méthode suivante entraînerait l'ignorance de toute demande commençant par /resources/à des fins d' authentification .

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

SecurityBuilder utilisé pour créer un fichier AuthenticationManager. Permet d'intégrer facilement l' authentification mémoire, l'authentification LDAP, l'authentification basée sur JDBC, l'ajout de UserDetailsService et l'ajout d'AuthenticationProvider .

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

très bonne réponse. Je me demande si nous devons appeler permitAll sur HttpSecurity? Ne pouvons-nous pas simplement ignorer toutes les URL ouvertes comme / register ou / login en utilisant WebSecurity? Alors pourquoi tous les didacticiels ou réponses utilisent HttpSecurity.permitAll pour / register et / login mais WebSecurity.ingore pour / publics of / resources?
Mohd Waseem le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.