Servlet過濾器被用來攔截用戶請求來進行請求以前或以後的處理,或者乾脆重定向這個請求,這取決於servlet過濾器的功能。java
Servlet過濾器處理以後的目標servlet是 MVC 分發web servlet。web
servlet請求按照必定的順序從一個過濾器到下一個穿過整個過濾器鏈,最終到達目標servlet。與之相對的是,當servelt處理完請求並返回一個response時,過濾器鏈按照相反的順序再次穿過全部的過濾器。spring
Spring Security利用Spring在XML配置文件中的自動配置屬性,創建了十個servlet過濾器,這些過濾器並無配置在web.xml中,而是由Spring Factory使用JavaEE的servlet過濾器鏈將他們按順序組裝。數據庫
Spring Security使用了過濾器鏈的實現了本身的抽象,提供了VirtualFilterChain,它能夠根據Spring Security XML配置文件中設置的URL模式動態的建立過濾器鏈(能夠將它與標準的Java EE過濾器鏈進行對比,後者須要在web應用的部署描述文件中進行設置)。api
Spring Security的自動配置選項auto-config爲你創建了十個Spring Security的過濾器。這些過濾器以及它們使用的順序,在下面的表格中進行了描述。安全
如:UsernamePasswordAuthenticationFilter是經過<http>配置指令的<form-login>子元素來進行配置的。session
過濾器名稱app |
描述ide |
o.s.s.web.context.SecurityContextPersistenceFilterui |
負責從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() |
返回一個跟認證提供者相關的安全實體細節信息
|