Spring Security - aucune sécurité, aucun filtre, autorisation d'accèsTous
1. Vue d'ensemble
Spring Security fournit plusieurs mécanismes pour configurer un modèle de demande non sécurisé ou autorisant tous les accès. En fonction de chacun de ces mécanismes, cela peut signifier soit de ne pas exécuter la chaîne de filtres de sécurité sur ce chemin, soit d'exécuter la chaîne de filtres et d'autoriser l'accès.
Lectures complémentaires:
Spring Security - Rôles et privilèges
Comment mapper des rôles et des privilèges pour une application Spring Security: la configuration, l’authentification et le processus d’enregistrement.
Spring Security pour une API REST
Comment sécuriser une API REST avec Spring Security - la configuration XML, le fichier web.xml, les codes d'état HTTP pour l'authentification, etc.
Spring Security Expressions - Exemple de rôle
Introduction à l'expression de sécurité hasRole Spring: configurez l'autorisation Web par URL et par page, ainsi que la sécurité de la méthode avec @PreAuthorize.
2. access=”permitAll”
La configuration d'un élément<intercept-url> avecaccess=”permitAll” configurera l'autorisation de sorte que toutes les requêtes soientallowed sur ce chemin particulier:
Ou, via la configuration Java:
http.authorizeRequests().antMatchers("/login*").permitAll();Ceci est atteintwithout disabling the security filters - ceux-ci fonctionnent toujours, donc toutes les fonctionnalités liées à Spring Security seront toujours disponibles.
3. filters=”none”
Ceci est une fonctionnalité pré-Spring 3.1 qui a étédeprecated and replaced in Spring 3.1.
L'attributfilters désactive entièrement la chaîne de filtres Spring Security sur ce chemin de requête particulier:
Cela peut entraîner des problèmes lorsque le traitement de la demande nécessitera certaines fonctionnalités de Spring Security.
Comme il s'agit d'une fonctionnalité obsolète des versions de Spring plus récentes que la version 3.0, son utilisation avec Spring 3.1 donnera lieu à une exception d'exécution au démarrage:
SEVERE: Context initialization failed
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: The use of "filters='none'" is no longer supported.
Please define a separate element for the pattern you want to exclude
and use the attribute "security='none'".
Offending resource: class path resource [webSecurityConfig.xml]
at o.s.b.f.p.FailFastProblemReporter.error(FailFastProblemReporter.java:68) 4. security=”none”
Comme nous l'avons vu dans le message d'erreur ci-dessus, Spring 3.1 remplacefilters=”none” par une nouvelle expression -security=”none”.
La portée a également changé - ceci n'est plus spécifié au niveau de l'élément<intercept-url>. Au lieu de cela, Spring 3.1 permet de définirmultiple <http> elements - chacun avec sa propre configuration de chaîne de filtres de sécurité. Et donc, le nouvel attribut de sécurité appartient désormais au niveau de l'élément<http>.
En pratique, cela ressemblera à:
Ou avec la configuration Java:
web.ignoring().antMatchers("/resources/**");Au lieu de l'ancien:
Semblable àfilters=”none”, cela désactivera également complètement la chaîne de filtres de sécurité pour ce chemin de requête - donc lorsque la requête est traitée dans l'application, les fonctionnalités de Spring Security ne seront pas disponibles.
Ce n'est pas un problème pour les exemples ci-dessus, qui traitent principalement deserving static resources - où aucun traitement réel n'a lieu. Cependant, si la demande est gérée par programme d'une manière ou d'une autre, les fonctionnalités de sécurité telles querequires-channel, l'accès à l'utilisateur actuel ou l'appel de méthodes sécurisées ne seront pas disponibles.
Pour la même raison, il est inutile de spécifier des attributs supplémentaires sur un élément<http> qui a déjà été configuré avecsecurity=”none” car ce chemin de requête n'est pas sécurisé et les attributs seront simplement ignorés.
Alternativement,access='IS_AUTHENTICATED_ANONYMOUSLY' peut être utilisé pour autoriser l'accès anonyme.
5. Mises en garde poursecurity=”none”
Lorsque vous utilisez plusieurs éléments<http>, certains configurés avecsecurity=”none”, gardez à l'esprit que l'ordre dans lequel ces éléments sont définis est important. Nous voulons avoir les chemins<http> spécifiques en premier, suivis du modèle universel à la toute fin.
Notez également que, si un élément<http>doesn’t specify a pattern, alors par défaut, il correspond au modèle de correspondance universel - "/*” – so again, this element needs to be last. If the order of the elements is not correct, the *creation of the security filter chain will fail:
Caused by: java.lang.IllegalArgumentException: A universal match pattern ('/**')
is defined before other patterns in the filter chain, causing them to be ignored.
Please check the ordering in your namespace or FilterChainProxy bean configuration
at o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder(DefaultFilterChainValidator.java:49)
at o.s.s.c.h.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:39) 6. Conclusion
Cet article décrit les options permettant d'autoriser l'accès à un chemin avec Spring Security - en se concentrant sur les différences entrefilters=”none”, security=”none” and access=”permitAll”.
Comme d'habitude, les exemples sont disponiblesover on GitHub.