Fonctionnement de Spring Security Filter Chain

Je me rends compte que la sécurité Spring s'appuie sur une chaîne de filtres, qui interceptera la demande, détectera (l'absence) d'authentification, redirigera vers le point d'entrée d'authentification ou transmettra la demande au service d'autorisation, et finira par laisser la demande frapper le servlet ou lancer une exception de sécurité (non authentifié ou non autorisé). DelegatingFitlerProxy colle ces filtres ensemble. Pour effectuer leurs tâches, ces filtres accèdent aux services tels que UserDetailsService et AuthenticationManager .

Les filtres clés de la chaîne sont (dans l'ordre)

• SecurityContextPersistenceFilter (restaure l'authentification à partir de JSESSIONID)
• UsernamePasswordAuthenticationFilter (effectue l'authentification)
• ExceptionTranslationFilter (intercepter les exceptions de sécurité de FilterSecurityInterceptor)
• FilterSecurityInterceptor (peut lever des exceptions d'authentification et d'autorisation)

Je ne sais pas comment ces filtres sont utilisés. Est-ce que pour le formulaire de connexion fourni par le printemps, UsernamePasswordAuthenticationFilter n'est utilisé que pour / login , et les derniers filtres ne le sont pas? L' élément d'espace de noms form-login configure-t-il automatiquement ces filtres? Est-ce que chaque demande (authentifiée ou non) atteint FilterSecurityInterceptor pour une URL sans connexion?

Que faire si je souhaite sécuriser mon API REST avec un jeton JWT , qui est récupéré lors de la connexion? Je dois configurer deux httpbalises de configuration d'espace de noms , des droits? Un pour / login avec UsernamePasswordAuthenticationFilter, et un autre pour les URL REST, avec custom JwtAuthenticationFilter.

La configuration de deux httpéléments en crée- springSecurityFitlerChainst-elle deux ? Est UsernamePasswordAuthenticationFilter-il désactivé par défaut, jusqu'à ce que je déclare form-login? Comment puis-je remplacer SecurityContextPersistenceFilterpar un filtre qui obtiendra Authenticationde l'existant JWT-tokenplutôt que JSESSIONID?

La chaîne de filtres de sécurité Spring est un moteur très complexe et flexible.

Les filtres clés de la chaîne sont (dans l'ordre)

• SecurityContextPersistenceFilter (restaure l'authentification à partir de JSESSIONID)
• UsernamePasswordAuthenticationFilter (effectue l'authentification)
• ExceptionTranslationFilter (intercepter les exceptions de sécurité de FilterSecurityInterceptor)
• FilterSecurityInterceptor (peut lever des exceptions d'authentification et d'autorisation)

En regardant la documentation actuelle de la version stable 4.2.1 , section 13.3 Ordre des filtres, vous pouvez voir toute l'organisation des filtres de la chaîne de filtres:

13.3 Ordre des filtres

L'ordre dans lequel les filtres sont définis dans la chaîne est très important. Quels que soient les filtres que vous utilisez réellement, l'ordre doit être le suivant:

1. ChannelProcessingFilter , car il peut avoir besoin de rediriger vers un autre protocole

2. SecurityContextPersistenceFilter , de sorte qu'un SecurityContext peut être configuré dans le SecurityContextHolder au début d'une requête Web, et toute modification apportée au SecurityContext peut être copiée dans HttpSession lorsque la requête Web se termine (prête à être utilisée avec la prochaine requête Web)

3. ConcurrentSessionFilter , car il utilise la fonctionnalité SecurityContextHolder et doit mettre à jour SessionRegistry pour refléter les demandes en cours du principal

4. Mécanismes de traitement d'authentification - UsernamePasswordAuthenticationFilter , CasAuthenticationFilter , BasicAuthenticationFilter, etc. - afin que le SecurityContextHolder puisse être modifié pour contenir un jeton de demande d'authentification valide

5. Le SecurityContextHolderAwareRequestFilter , si vous utilisez pour installer un courant de sécurité Spring HttpServletRequestWrapper dans votre conteneur de servlets

6. Le JaasApiIntegrationFilter , si un JaasAuthenticationToken est dans le SecurityContextHolder, cela traitera le FilterChain en tant que sujet dans le JaasAuthenticationToken

7. RememberMeAuthenticationFilter , de sorte que si aucun mécanisme de traitement d'authentification antérieur n'a mis à jour le SecurityContextHolder, et que la demande présente un cookie qui permet aux services de se souvenir de moi, un objet d'authentification mémorisé approprié y sera placé

8. AnonymousAuthenticationFilter , de sorte que si aucun mécanisme de traitement d'authentification antérieur n'a mis à jour le SecurityContextHolder, un objet d'authentification anonyme y sera placé

9. ExceptionTranslationFilter , pour intercepter les exceptions Spring Security afin qu'une réponse d'erreur HTTP puisse être renvoyée ou qu'un AuthenticationEntryPoint approprié puisse être lancé

10. FilterSecurityInterceptor , pour protéger les URI Web et lever des exceptions lorsque l'accès est refusé

Maintenant, je vais essayer de poursuivre vos questions une par une:

Je ne sais pas comment ces filtres sont utilisés. Est-ce que pour le formulaire de connexion fourni par le printemps, UsernamePasswordAuthenticationFilter n'est utilisé que pour / login, et les derniers filtres ne le sont pas? L'élément d'espace de noms form-login configure-t-il automatiquement ces filtres? Est-ce que chaque demande (authentifiée ou non) atteint FilterSecurityInterceptor pour une URL sans connexion?

Une fois que vous avez configuré une <security-http>section, pour chacune, vous devez au moins fournir un mécanisme d'authentification. Cela doit être l'un des filtres qui correspondent au groupe 4 dans la section 13.3 Ordre des filtres de la documentation Spring Security que je viens de citer.

C'est l'élément de sécurité minimum valide: http qui peut être configuré:

<security:http authentication-manager-ref="mainAuthenticationManager" 
               entry-point-ref="serviceAccessDeniedHandler">
    <security:intercept-url pattern="/sectest/zone1/**" access="hasRole('ROLE_ADMIN')"/>
</security:http>

Juste en faisant cela, ces filtres sont configurés dans le proxy de la chaîne de filtres:

{
        "1": "org.springframework.security.web.context.SecurityContextPersistenceFilter",
        "2": "org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter",
        "3": "org.springframework.security.web.header.HeaderWriterFilter",
        "4": "org.springframework.security.web.csrf.CsrfFilter",
        "5": "org.springframework.security.web.savedrequest.RequestCacheAwareFilter",
        "6": "org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter",
        "7": "org.springframework.security.web.authentication.AnonymousAuthenticationFilter",
        "8": "org.springframework.security.web.session.SessionManagementFilter",
        "9": "org.springframework.security.web.access.ExceptionTranslationFilter",
        "10": "org.springframework.security.web.access.intercept.FilterSecurityInterceptor"
    }

Remarque: je les reçois en créant un simple RestController qui @Autowires le FilterChainProxy et renvoie son contenu:

    @Autowired
    private FilterChainProxy filterChainProxy;

    @Override
    @RequestMapping("/filterChain")
    public @ResponseBody Map<Integer, Map<Integer, String>> getSecurityFilterChainProxy(){
        return this.getSecurityFilterChainProxy();
    }

    public Map<Integer, Map<Integer, String>> getSecurityFilterChainProxy(){
        Map<Integer, Map<Integer, String>> filterChains= new HashMap<Integer, Map<Integer, String>>();
        int i = 1;
        for(SecurityFilterChain secfc :  this.filterChainProxy.getFilterChains()){
            //filters.put(i++, secfc.getClass().getName());
            Map<Integer, String> filters = new HashMap<Integer, String>();
            int j = 1;
            for(Filter filter : secfc.getFilters()){
                filters.put(j++, filter.getClass().getName());
            }
            filterChains.put(i++, filters);
        }
        return filterChains;
    }

Ici, nous avons pu voir qu'en déclarant simplement l' <security:http>élément avec une configuration minimale, tous les filtres par défaut sont inclus, mais aucun d'entre eux n'est de type Authentification (4ème groupe dans la section 13.3 Trier les filtres). Cela signifie donc en fait qu'en déclarant simplement l' security:httpélément, SecurityContextPersistenceFilter, ExceptionTranslationFilter et FilterSecurityInterceptor sont auto-configurés.

En fait, un mécanisme de traitement d'authentification doit être configuré, et même les beans d'espace de noms de sécurité traitant des revendications pour cela, lançant une erreur au démarrage, mais il peut être contourné en ajoutant un attribut entry-point-ref dans <http:security>

Si j'ajoute un élément <form-login>de base à la configuration, de cette façon:

<security:http authentication-manager-ref="mainAuthenticationManager">
    <security:intercept-url pattern="/sectest/zone1/**" access="hasRole('ROLE_ADMIN')"/>
    <security:form-login />
</security:http>

Maintenant, le filterChain sera comme ceci:

{
        "1": "org.springframework.security.web.context.SecurityContextPersistenceFilter",
        "2": "org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter",
        "3": "org.springframework.security.web.header.HeaderWriterFilter",
        "4": "org.springframework.security.web.csrf.CsrfFilter",
        "5": "org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter",
        "6": "org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter",
        "7": "org.springframework.security.web.savedrequest.RequestCacheAwareFilter",
        "8": "org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter",
        "9": "org.springframework.security.web.authentication.AnonymousAuthenticationFilter",
        "10": "org.springframework.security.web.session.SessionManagementFilter",
        "11": "org.springframework.security.web.access.ExceptionTranslationFilter",
        "12": "org.springframework.security.web.access.intercept.FilterSecurityInterceptor"
    }

Maintenant, ces deux filtres org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter et org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter sont créés et configurés dans FilterChainProxy.

Alors, maintenant, les questions:

Est-ce que pour le formulaire de connexion fourni par le printemps, UsernamePasswordAuthenticationFilter n'est utilisé que pour / login, et les derniers filtres ne le sont pas?

Oui, il est utilisé pour essayer de terminer un mécanisme de traitement de connexion au cas où la demande correspond à l'url UsernamePasswordAuthenticationFilter. Cette URL peut être configurée ou même modifiée son comportement pour correspondre à chaque demande.

Vous pouvez également avoir plus d'un mécanisme de traitement d'authentification configuré dans le même FilterchainProxy (tel que HttpBasic, CAS, etc.).

L'élément d'espace de noms form-login configure-t-il automatiquement ces filtres?

Non, l'élément form-login configure le UsernamePasswordAUthenticationFilter, et si vous ne fournissez pas d'URL de page de connexion, il configure également org.springframework.security.web.authentication.ui.DefaultLoginPageGeneratingFilter, qui se termine par une simple connexion générée automatiquement page.

Les autres filtres sont auto-configurés par défaut simplement en créant un <security:http>élément sans security:"none"attribut.

Est-ce que chaque demande (authentifiée ou non) atteint FilterSecurityInterceptor pour une URL sans connexion?

Chaque requête doit l'atteindre, car c'est l'élément qui vérifie si la requête a le droit d'atteindre l'url demandée. Mais certains des filtres traités auparavant peuvent arrêter le traitement de la chaîne de filtres tout simplement ne pas appeler FilterChain.doFilter(request, response);. Par exemple, un filtre CSRF peut arrêter le traitement de la chaîne de filtres si la demande n'a pas le paramètre csrf.

Que faire si je souhaite sécuriser mon API REST avec un jeton JWT, qui est récupéré lors de la connexion? Je dois configurer deux balises http de configuration d'espace de noms, des droits? Un autre pour / login avec UsernamePasswordAuthenticationFilter, et un autre pour les URL REST, avec custom JwtAuthenticationFilter.

Non, vous n'êtes pas obligé de faire de cette façon. Vous pouvez déclarer les deux UsernamePasswordAuthenticationFilteret le JwtAuthenticationFilterdans le même élément http, mais cela dépend du comportement concret de chacun de ces filtres. Les deux approches sont possibles, et celle à choisir dépend finalement de ses propres préférences.

La configuration de deux éléments http crée-t-elle deux springSecurityFitlerChains?

Oui c'est vrai

UsernamePasswordAuthenticationFilter est-il désactivé par défaut, jusqu'à ce que je déclare la connexion par formulaire?

Oui, vous pouvez le voir dans les filtres soulevés dans chacune des configurations que j'ai postées

Comment remplacer SecurityContextPersistenceFilter par un, qui obtiendra l'authentification du jeton JWT existant plutôt que de JSESSIONID?

Vous pouvez éviter SecurityContextPersistenceFilter, en configurant simplement la stratégie de session dans <http:element>. Configurez simplement comme ceci:

<security:http create-session="stateless" >

Ou, dans ce cas, vous pouvez l'écraser avec un autre filtre, de cette façon à l'intérieur de l' <security:http>élément:

<security:http ...>  
   <security:custom-filter ref="myCustomFilter" position="SECURITY_CONTEXT_FILTER"/>    
</security:http>
<beans:bean id="myCustomFilter" class="com.xyz.myFilter" />

ÉDITER:

Une question sur "Vous pourriez aussi avoir plus d'un mécanisme de traitement d'authentification configuré dans le même FilterchainProxy". Ce dernier écrasera-t-il l'authentification effectuée par le premier, si vous déclarez plusieurs filtres d'authentification (implémentation Spring)? En quoi cela est-il lié au fait d'avoir plusieurs fournisseurs d'authentification?

Cela dépend finalement de l'implémentation de chaque filtre lui-même, mais c'est vrai que ces derniers filtres d'authentification au moins sont capables d'écraser toute authentification antérieure éventuellement faite par les filtres précédents.

Mais cela n'arrivera pas nécessairement. J'ai des cas de production dans des services REST sécurisés où j'utilise une sorte de jeton d'autorisation qui peut être fourni à la fois en tant qu'en-tête Http ou dans le corps de la requête. Je configure donc deux filtres qui récupèrent ce jeton, dans un cas à partir de l'en-tête Http et l'autre à partir du corps de la requête de la propre requête de repos. Il est vrai que si une requête http fournit ce jeton d'authentification à la fois comme en-tête Http et à l'intérieur du corps de la requête, les deux filtres essaieront d'exécuter le mécanisme d'authentification en le déléguant au gestionnaire, mais cela pourrait être facilement évité de simplement vérifier si la requête est déjà authentifié juste au début de la doFilter()méthode de chaque filtre.

Avoir plus d'un filtre d'authentification est lié au fait d'avoir plus d'un fournisseur d'authentification, mais ne le forcez pas. Dans le cas que j'ai exposé auparavant, j'ai deux filtres d'authentification mais je n'ai qu'un seul fournisseur d'authentification, car les deux filtres créent le même type d'objet d'authentification, donc dans les deux cas, le gestionnaire d'authentification le délègue au même fournisseur.

Et à l'opposé de cela, j'ai aussi un scénario dans lequel je publie un seul UsernamePasswordAuthenticationFilter mais les informations d'identification de l'utilisateur peuvent toutes deux être contenues dans DB ou LDAP, j'ai donc deux fournisseurs de support UsernamePasswordAuthenticationToken, et AuthenticationManager délègue toute tentative d'authentification du filtre aux fournisseurs Secuentially pour valider les informations d'identification.

Donc, je pense qu'il est clair que ni le nombre de filtres d'authentification ne détermine le nombre de fournisseurs d'authentification ni le nombre de fournisseurs ne déterminent le nombre de filtres.

En outre, la documentation indique que SecurityContextPersistenceFilter est responsable du nettoyage du SecurityContext, ce qui est important en raison du pool de threads. Si je l'omets ou si je propose une implémentation personnalisée, je dois implémenter le nettoyage manuellement, non? Y a-t-il d'autres pièges similaires lors de la personnalisation de la chaîne?

Je n'ai pas examiné attentivement ce filtre auparavant, mais après votre dernière question, j'ai vérifié sa mise en œuvre et, comme d'habitude au printemps, presque tout pourrait être configuré, étendu ou écrasé.

Les SecurityContextPersistenceFilter délégués dans une SecurityContextRepository mise en œuvre de la recherche pour la SecurityContext. Par défaut, un HttpSessionSecurityContextRepository est utilisé, mais cela peut être modifié à l'aide de l'un des constructeurs du filtre. Il peut donc être préférable d'écrire un SecurityContextRepository qui correspond à vos besoins et de le configurer simplement dans SecurityContextPersistenceFilter, en faisant confiance à son comportement prouvé plutôt que de commencer à tout faire à partir de zéro.

UsernamePasswordAuthenticationFilterest uniquement utilisé pour /login, et les derniers filtres ne le sont pas?

Non, UsernamePasswordAuthenticationFilterétend AbstractAuthenticationProcessingFilter, et cela contient un RequestMatcher, cela signifie que vous pouvez définir votre propre url de traitement, ce filtre ne gère que les RequestMatchercorrespondances à l'url de la demande, l'URL de traitement par défaut est /login.

Les filtres ultérieurs peuvent toujours gérer la demande, si le UsernamePasswordAuthenticationFilterfichier s'exécute chain.doFilter(request, response);.

Plus de détails sur les core fitlers

L'élément d'espace de noms form-login configure-t-il automatiquement ces filtres?

UsernamePasswordAuthenticationFilterest créé par <form-login>, il s'agit d' alias de filtre standard et de classement

Est-ce que chaque demande (authentifiée ou non) atteint FilterSecurityInterceptor pour une URL sans connexion?

Cela dépend de la réussite des fitlers avant, mais FilterSecurityInterceptorc'est normalement le dernier fitler.

La configuration de deux éléments http crée-t-elle deux springSecurityFitlerChains?

Oui, chaque fitlerChain a un RequestMatcher, si le RequestMatchercorrespond à la demande, la demande sera gérée par les fitler dans la chaîne fitler.

La valeur par défaut RequestMatchercorrespond à toutes les requêtes si vous ne configurez pas le modèle, ou vous pouvez configurer l'url spécifique ( <http pattern="/rest/**").

Si vous voulez en savoir plus sur les fitlers, je pense que vous pouvez vérifier le code source dans Spring Security. doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain)

Spring Security est un framework basé sur des filtres, il plante un WALL (HttpFireWall) avant votre application en termes de filtres proxy ou de beans gérés par spring. Votre demande doit passer par plusieurs filtres pour atteindre votre API.

Séquence d'exécution dans Spring Security

1. WebAsyncManagerIntegrationFilter Fournit une intégration entre SecurityContext et WebAsyncManager de Spring Web.
   

2. SecurityContextPersistenceFilterCe filtre ne s'exécutera qu'une fois par demande, remplit le SecurityContextHolder avec les informations obtenues à partir du SecurityContextRepository configuré avant la demande et le stocke de nouveau dans le référentiel une fois la demande terminée et en effaçant le détenteur du contexte.
   La demande est vérifiée pour la session existante. Si une nouvelle demande, SecurityContext sera créée, sinon si la demande a une session, le contexte de sécurité existant sera obtenu à partir du référentiel .

3. HeaderWriterFilter Filtrer l'implémentation pour ajouter des en-têtes à la réponse actuelle.

4. LogoutFilterSi l'URL de la requête est /logout(pour la configuration par défaut) ou si l'URL de la requête est RequestMatcherconfigurée dans LogoutConfigureralors

   • efface le contexte de sécurité.
   • invalide la session
   • supprime tous les cookies avec des noms de cookies configurés dans LogoutConfigurer
   • Redirige vers l'URL de réussite de déconnexion par défaut /ou l' URL de réussite de déconnexion configurée ou appelle logoutSuccessHandler configuré.

5. UsernamePasswordAuthenticationFilter

   • Pour toute URL de demande autre que loginProcessingUrl, ce filtre ne sera plus traité mais la chaîne de filtres continue.
   • Si l'URL demandée correspond (doit être HTTP POST) par défaut /loginou correspond à la .loginProcessingUrl()configuration, FormLoginConfigureralors UsernamePasswordAuthenticationFiltertente l'authentification.
   • les paramètres par défaut du formulaire de connexion sont le nom d' utilisateur et mot de passe, peuvent être remplacées par usernameParameter(String), passwordParameter(String).
   • le paramètre .loginPage() remplace les valeurs par défaut
   • Lors de la tentative d'authentification
     • un Authenticationobjet ( UsernamePasswordAuthenticationTokenou toute implémentation de Authenticationdans le cas de votre filtre d'authentification personnalisé) est créé.
     • et authenticationManager.authenticate(authToken)sera invoqué
       
     • Notez que nous pouvons configurer n'importe quel nombre de AuthenticationProviderméthodes d'authentification essayant tous les fournisseurs d' authentification et vérifie l'un des supportsobjets authToken / authentication du fournisseur d' authentification, le fournisseur d' authentification prenant en charge sera utilisé pour l'authentification. et renvoie l'objet d'authentification en cas d'authentification réussie, sinon AuthenticationException.
   • Si l'authentification réussie, une session sera créée et authenticationSuccessHandlersera appelée, ce qui redirigera vers l'URL cible configurée (la valeur par défaut est /)
   • Si l'authentification échoue, l'utilisateur devient un utilisateur non authentifié et la chaîne se poursuit.

6. SecurityContextHolderAwareRequestFilter, si vous l'utilisez pour installer un HttpServletRequestWrapper prenant en charge Spring Security dans votre conteneur de servlet

7. AnonymousAuthenticationFilterDétecte s'il n'y a pas d'objet d'authentification dans SecurityContextHolder, si aucun objet d'authentification n'a été trouvé, crée Authenticationobject ( AnonymousAuthenticationToken) avec l'autorisation accordée ROLE_ANONYMOUS. Ici AnonymousAuthenticationTokenfacilite l'identification des demandes ultérieures des utilisateurs non authentifiés.
   

DEBUG - /app/admin/app-config at position 9 of 12 in additional filter chain; firing Filter: 'AnonymousAuthenticationFilter'
DEBUG - Populated SecurityContextHolder with anonymous token: 'org.springframework.security.authentication.AnonymousAuthenticationToken@aeef7b36: Principal: anonymousUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@b364: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 

8. ExceptionTranslationFilter, pour intercepter toutes les exceptions Spring Security afin qu'une réponse d'erreur HTTP puisse être renvoyée ou qu'un AuthenticationEntryPoint approprié puisse être lancé

9. FilterSecurityInterceptor
   Il y aura ce FilterSecurityInterceptorqui arrive presque en dernier dans la chaîne de filtrage qui obtient l'objet d'authentification SecurityContextet obtient la liste des autorités accordées (rôles accordés) et il prendra la décision d'autoriser ou non cette demande à atteindre la ressource demandée, la décision est prise en faisant correspondre avec le autorisé AntMatchersconfiguré dans HttpSecurityConfiguration.

Considérez les exceptions 401-UnAuthorized et 403-Forbidden. Ces décisions seront prises au dernier dans la chaîne de filtrage

• Un utilisateur authentifié essayant d'accéder à une ressource publique - Autorisé
  
• Un utilisateur authentifié essayant d'accéder à une ressource sécurisée - 401-UnAuthorized
  
• Utilisateur authentifié essayant d'accéder à une ressource restreinte (restreinte pour son rôle) - 403-Interdit
  

Remarque: l' utilisateur demande des flux non seulement dans les filtres ci - dessus mentionnés, mais il y a les autres filtres trop non représentés ici (. ConcurrentSessionFilter, RequestCacheAwareFilter, SessionManagementFilter...)
Ce sera différent lorsque vous utilisez votre filtre auth personnalisé au lieu de UsernamePasswordAuthenticationFilter.
Ce sera différent si vous configurez le filtre d'authentification JWT et que vous l'omettez, .formLogin() i.e, UsernamePasswordAuthenticationFilterce sera un cas entièrement différent.

De la documentation, l' ordre des filtres est donné comme

• ChannelProcessingFilter
• ConcurrentSessionFilter
• SecurityContextPersistenceFilter
• DéconnexionFiltre
• X509AuthenticationFilter
• AbstractPreAuthenticatedProcessingFilter
• CasAuthenticationFilter
• Nom d'utilisateurPasswordAuthenticationFilter
• ConcurrentSessionFilter
• OpenIDAuthenticationFilter
• DefaultLoginPageGeneratingFilter
• DefaultLogoutPageGeneratingFilter
• ConcurrentSessionFilter
• DigestAuthenticationFilter
• BearerTokenAuthenticationFilter
• BasicAuthenticationFilter
• RequestCacheAwareFilter
• SecurityContextHolderAwareRequestFilter
• JaasApiIntegrationFilter
• RememberMeAuthenticationFilter
• AnonymousAuthenticationFilter
• SessionManagementFilter
• ExceptionTranslationFilter
• FilterSecurityInterceptor
• SwitchUserFilter

Vous pouvez également vous référer au
moyen le plus courant d'authentifier une application Web moderne?
différence entre l'authentification et l'autorisation dans le contexte de Spring Security?