Spring Security - sécurité aucune, filtre aucun, autorisation d'accès

1. Vue d'ensemble

Spring Security fournit plusieurs mécanismes pour configurer un modèle de demande comme non sécurisé ou autorisant tous les accès. En fonction de chacun de ces mécanismes, cela peut signifier de ne pas exécuter du tout la chaîne de filtres de sécurité sur ce chemin, ou d'exécuter la chaîne de filtres et d'autoriser l'accès.

2. access = "permitAll"

Mettre en place un element with access = ”permitAll” configurera l'autorisation afin que toutes les requêtes soient autorisées sur ce chemin particulier:

Ou, via la configuration Java:

http.authorizeRequests().antMatchers("/login*").permitAll();

Ceci est réalisé sans désactiver les filtres de sécurité - ceux-ci fonctionnent toujours, donc toutes les fonctionnalités liées à Spring Security seront toujours disponibles.

3. filters = "aucun"

Il s'agit d'une fonctionnalité antérieure à Spring 3.1 qui a été déconseillée et remplacée dans Spring 3.1.

L' attribut filters 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.

Puisqu'il s'agit d'une fonctionnalité obsolète, les versions Spring plus récentes que 3.0, son utilisation avec Spring 3.1 entraînera 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. sécurité = "aucun"

Comme nous l'avons vu dans le message d'erreur ci-dessus, Spring 3.1 remplace filters = "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. Au lieu de cela, Spring 3.1 autorise plusieurséléments à définir - 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.

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 demande 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 de la diffusion de ressources statiques - 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 que le canal requis, 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 qui a déjà été configuré avec security = "none" car ce chemin de requête n'est pas sécurisé et les attributs seront simplement ignorés.

Sinon, access = 'IS_AUTHENTICATED_ANONYMOUSLY' peut être utilisé pour autoriser l'accès anonyme.

5. Mises en garde pour la sécurité = "aucun"

Lors de l'utilisation de plusieurs éléments, certains configurés avec security = ”none” , gardez à l'esprit que l'ordre dans lequel ces éléments sont définis est important. Nous voulons avoir le spécifique chemins d'abord, a suivi le modèle universel à la toute fin.

Notez également que si un element ne spécifie pas de modèle , alors par défaut, qui correspond au modèle de correspondance universel - «/ **» - donc encore une fois, cet élément doit être le dernier. Si l'ordre des éléments n'est pas correct, la création de la chaîne de filtres de sécurité échouera :

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 entre les filtres = "none", security = "none" et access = "permitAll" .

Comme d'habitude, les exemples sont disponibles à l'adresse over sur GitHub.