Servlet過濾器被用來攔截用戶請求來進行請求之前或之后的處理，或者干脆重定向這個請求，這取決於servlet過濾器的功能。
Servlet過濾器處理之后的目標servlet是 MVC 分發web servlet。
servlet請求按照一定的順序從一個過濾器到下一個穿過整個過濾器鏈，最終到達目標servlet。與之相對的是，當servelt處理完請求並返回一個response時，過濾器鏈按照相反的順序再次穿過所有的過濾器。
Spring Security利用Spring在XML配置文件中的自動配置屬性，建立了十個servlet過濾器，這些過濾器並沒有配置在web.xml中，而是由Spring Factory使用JavaEE的servlet過濾器鏈將他們按順序組裝。
Spring Security使用了過濾器鏈的實現了自己的抽象，提供了VirtualFilterChain，它可以根據Spring Security XML配置文件中設置的URL模式動態的創建過濾器鏈（可以將它與標准的Java EE過濾器鏈進行對比，后者需要在web應用的部署描述文件中進行設置）。
Spring Security的自動配置選項auto-config為你建立了十個Spring Security的過濾器。這些過濾器以及它們使用的順序，在下面的表格中進行了描述。
如：UsernamePasswordAuthenticationFilter是通過<http>配置指令的<form-login>子元素來進行配置的。
| 過濾器名稱 |
描述 |
| o.s.s.web.context.SecurityContextPersistenceFilter |
負責從SecurityContextRepository獲取或存儲SecurityContext。SecurityContext代表了用戶安全和認證過的session。 |
| o.s.s.web.authentication.logout.LogoutFilter |
監控一個實際為退出功能的URL（默認為/j_spring_security_logout），並且在匹配的時候完成用戶的退出功能。 |
| o.s.s.web.authentication.UsernamePasswordAuthenticationFilter |
監控一個使用用戶名和密碼基於form認證的URL（默認為/j_spring_security_check），並在URL匹配的情況下嘗試認證該用戶。 |
| o.s.s.web.authentication.ui.DefaultLoginPageGeneratingFilter |
監控一個要進行基於forn或OpenID認證的URL（默認為/spring_security_login），並生成展現登錄form的HTML |
| o.s.s.web.authentication.www.BasicAuthenticationFilter |
監控HTTP 基礎認證的頭信息並進行處理 |
| o.s.s.web.savedrequest. RequestCacheAwareFilter |
用於用戶登錄成功后，重新恢復因為登錄被打斷的請求。 |
| o.s.s.web.servletapi. SecurityContextHolderAwareRequest Filter |
用一個擴展了HttpServletRequestWrapper的子類（o.s.s.web. servletapi.SecurityContextHolderAwareRequestWrapper）包裝HttpServletRequest。 它為請求處理器提供了額外的上下文信息。 |
| o.s.s.web.authentication. AnonymousAuthenticationFilter |
如果用戶到這一步還沒有經過認證，將會為這個請求關聯一個認證的token，標識此用戶是匿名的。 |
| o.s.s.web.session. SessionManagementFilter |
根據認證的安全實體信息跟蹤session，保證所有關聯一個安全實體的session都能被跟蹤到。 |
| o.s.s.web.access. ExceptionTranslationFilter |
解決在處理一個請求時產生的指定異常 |
| o.s.s.web.access.intercept. FilterSecurityInterceptor |
簡化授權和訪問控制決定，委托一個AccessDecisionManager完成授權的判斷 |
Spring Security擁有總共大約25個過濾器，它們能夠根據你的需要進行適當的應用以改變用戶請求的行為。
如果需要的話，你也可以添加你自己實現了javax.servlet.Filter接口的過濾器。
請記住，如果你在XML配置文件中使用了auto-config屬性，以上表格中列出的過濾器自動添加的。
通過使用一些額外的配置指令，以上列表中的過濾器能夠精確的控制是否被包含。
你可能想知道DelegatingFilterProxy是怎樣找到Spring Security配置的過濾器鏈的。讓我們回憶一下，在web.xml文件中，我們需要給DelegatingFilterProxy一個過濾器的名字：
| <filter> <filter-name>springSecurityFilterChain</filter-name> <filter-class> org.springframework.web.filter.DelegatingFilterProxy </filter-class> </filter> |
這個過濾器的名字並不是隨意配置的，實際上會跟根據這個名字把Spring Security織入到DelegatingFilterProxy。除非明確配置，否則DelegatingFilterProxy會在Spring WebApplicationContext中尋找同名的配置bean（名字是在filter-name中指明的）。
三個主要的組件負責這項重要的事情：
| 接口名 |
描述/角色 |
| AbstractAuthenticationProcessingFilter |
它在基於web的認證請求中使用。處理包含認證信息的請求，如認證信息可能是form POST提交的、SSO信息或者其他用戶提供的。創建一個部分完整的Authentication對象以在鏈中傳遞憑證信息。 |
| AuthenticationManager |
它用來校驗用戶的憑證信息，或者會拋出一個特定的異常（校驗失敗的情況）或者完整填充Authentication對象，將會包含了權限信息。 |
| AuthenticationProvider |
它為AuthenticationManager提供憑證校驗。一些AuthenticationProvider的實現基於憑證信息的存儲，如數據庫，來判定憑證信息是否可以被認可。 |
有兩個重要接口的實現是在認證鏈中被這些參與的類初始化的，它們用來封裝一個認證過（或還沒有認證過的）的用戶的詳細信息和權限。
o.s.s.core.Authentication是你以后要經常接觸到的接口，因為它存儲了用戶的詳細信息，包括唯一標識（如用戶名）、憑證信息（如密碼）以及本用戶被授予的一個或多個權限（o.s.s.core.
GrantedAuthority）。開發人員通常會使用Authentication對象來獲取用戶的詳細信息，或者使用自定義的認證實現以便在Authentication對象中增加應用依賴的額外信息。
以下列出了Authentication接口可以實現的方法：
| 方法簽名 |
描述 |
| Object getPrincipal() |
返回安全實體的唯一標識（如，一個用戶名） |
| Object getCredentials() |
返回安全實體的憑證信息 |
| List<GrantedAuthority> getAuthorities() |
得到安全實體的權限集合，根據認證信息的存儲決定的。 |
| Object getDetails() |
返回一個跟認證提供者相關的安全實體細節信息
|
