【導(dǎo)讀】.AcegiSecurity是什么?.認(rèn)證標(biāo)簽庫.........

　　

【正文】 pSessionContextIntegrationFilter (ASC是 allowSessionCreation的縮寫 ,是 HttpSessionContextIntegrationFilter的一個屬性 )。 因?yàn)?web服務(wù)不會為將來的請求提供一個 jsessionid，為這樣的用戶創(chuàng)建 HttpSessions是 浪費(fèi)的。如果你有一個需要最大限度的伸縮性的 高容量的應(yīng)用，我們建議你使用上述的方法。對于小的應(yīng)用，使用單一的HttpSessionContextIntegrationFilter (默認(rèn)的 allowSessionCreation設(shè)為 true)應(yīng)該足夠了。 說到生命周期問題，如果對 FilterChainProxy自身調(diào)用 init(FilterConfig) 和 destroy()方法，它會把它代理到底層的 filter。這樣 FilterChainProxy保證只初始化和析構(gòu)每個 filter一次，不論它在 FilterInvocationDefinitionSource中定義了多少次。你可以通過 FilterToBeanProxy的 lifecycle 初始化參數(shù)來控制這些方法是否被調(diào)用。如上面所討論的那樣，默認(rèn)所有 servlet 容器生命周期調(diào)用是不被代理到 FilterChainProxy的。 在 中定義的 filter的順序是非常重要的。不管你實(shí)際用到哪個 filter，的順序應(yīng)該是如下所示的： 1． ChannelProcessingFilter，因?yàn)榭赡芤囟ㄏ虻搅硪环N協(xié)議。 2． ConcurrentSessionFilter 因?yàn)椴皇褂萌魏?SecurityContextHolder的功能，但是需要更新 SessionRegistry來表示當(dāng)前的發(fā)送請求的 principal。 3． HttpSessionContextIntegrationFilter, 這樣當(dāng)一個 web請求開始的時候就可以在 SecurityContextHolder中設(shè)置一個 SecurityContext，當(dāng) web請求結(jié)束的時候 任何對 SecurityContext的改動都會被 copy到 HttpSession（以備下一個 web請求使用）。 4． Authentication processing mechanisms AuthenticationProcessingFilter, CasProcessingFilter, BasicProcessingFilter, HttpRequestIntegrationFilter, JbossIntegrationFilter 等 修改 SecurityContextHolder，使其中包含一個有效的認(rèn)證請求令牌（ token）。 5． SecurityContextHolderAwareRequestFilter, 如果你使用它來在你的servlet 容器中安裝一個 Acegi Security aware HttpServletRequestWrapper。 6． RememberMeProcessingFilter, 如果早期的認(rèn)證處理過程沒有更新SecurityContextHolder，并且請求（ request）提供了一個 cookie啟用remember me 服務(wù)，一個合適的被記住的 Authentication對象會被放到SecurityContextHolder那里。 7． AnonymousProcessingFilter, 如果早期的認(rèn)證處理過程沒有更新SecurityContextHolder， , 一個匿名 Authentication 對象會被放到SecurityContextHolder那里。 8． ExceptionTranslationFilter, 捕獲所有的 Acegi Security 異常，這樣要么返回一個 HTTP錯誤響應(yīng)或者加載一個對應(yīng)的 AuthenticationEntryPoint。 9． FilterSecurityInterceptor, 保護(hù) web URIs 所有上述的 filter使用 FilterToBeanProxy或 FilterChainProxy。建議在一個應(yīng)用中使用一個單個的 FilterToBeanProxy代理到一個單個的FilterChainProxy。，在 FilterChainProxy中定義所有的 Acegi Security Filters。如果你使用 SiteMesh，確保 Acegi Security filters 在 SiteMesh filters 調(diào)用前調(diào)用。這樣使 SecurityContextHolder在 SiteMesh decorator使用前 能夠 acegi參考手冊 ()[譯 ]第四章 信道安全 第四章 . 信道安全 . 概述 Acegi Security不僅能滿足你的認(rèn)證和授權(quán)的請求，而且能夠保證你的未認(rèn)證的 web請求也能擁有某些屬性。這些屬性可能包括使用特定的傳輸類型，在HttpSession設(shè)置特定的屬性等等。 Web請求的最普遍的需求是使用特定的傳輸協(xié)議，例如 HTTPS。 在傳輸安全中的一個重要議題就是會話劫持（ session hijacking）。 Web容器通過一個 jsessionid來引用一個 HttpSession， 這個 jsessionid通過 cookie 或者 URL重寫轉(zhuǎn)向（ URL rewriting）發(fā)送到到客戶端。如果 jsessionid是通過 HTTP發(fā)送的，那么就存在被劫持以及在認(rèn)證過程之后冒充被認(rèn)證用戶的可能。這是因 為大部分的 web容器為特定的用戶維護(hù)同一個會話標(biāo)識符，即便是用戶從 HTTP 切換到 HTTPS頁面。 如果對于你的特定應(yīng)用來說，會話劫持（ session hijacking）是一個很嚴(yán)重的風(fēng)險(xiǎn)，那么唯一的解決方法就是對每一個請求都使用 HTTPS。這意味著jsessionid不會使用非安全信道傳輸 。 你要保證你的 中定義，把它指向一個 HTTPS位置，同時應(yīng)用程序不把用戶指向一個 HTTP位置。 Acegi Security提供一個解決方案幫助你實(shí)現(xiàn)后者。 . 配置 啟用 Acegi Security的信道安全服務(wù)，需要在 中增加如下行： xml 代碼 1. filter 2. filternameAcegi Channel Processing Filter/filtername 3. filterclass/filterclass 4. initparam 5. paramnametargetClass/paramname 6. paramvalueelProcessingFilter/paramvalue 7. /initparam 8. /filterfiltermapping 9. filternameAcegi Channel Processing Filter/filtername 10. urlpattern/*/urlpattern 11. /filtermapping 和平時一樣，你同樣需要在 application context 中配置 filter java 代碼 1. channelProcessingFilter class= 2. channelDecisionManagerchannelDecisionManager/ 3. filterInvocationDefinitionSource 4. 5. CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON 6. \A/secure/.*\Z=REQUIRES_SECURE_CHANNEL 7. \A/.*\Z=REQUIRES_SECURE_CHANNEL 8. \A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL 9. \A.*\Z=REQUIRES_INSECURE_CHANNEL 10. 11. 12. 13. 14. channelDecisionManager class= 15. channelProcessors 16. 17. secureChannelProcessor/ 18. insecureChannelProcessor/ 19. 20. 21. 22. 23. secureChannelProcessor class=/ 24. 25. insecureChannelProcessor class=/ ChannelProcessingFilter和 FilterSecurityInterceptor一樣支持 Apache Ant style paths。 ChannelProcessingFilter的工作方式是過濾所有的 web請求，并將判斷將適合的配置屬性應(yīng)用于其上。然后它代理到 ChannelDecisionManager。默認(rèn)的實(shí)現(xiàn)類 ChannelDecisionManagerImpl 應(yīng)該能夠滿足大多數(shù)需求。它就代理到 配置好的 ChannelProcessor實(shí)例列表。 ChannelProcessor會檢視請求，如果它不滿意請求（例如請求是發(fā)送自不正確的傳輸協(xié) 議）它將會重定向，拋出異常或者采取其他任何恰當(dāng)?shù)拇胧? Acegi Security 包括 ChannelProcessor兩個實(shí)體類實(shí)現(xiàn)：SecureChannelProcessor 保證配置了 REQUIRES_SECURE_CHANNEL 屬性的請求都是從 HTTPS發(fā)送過來的。而 InsecureChannelProcessor 保證配置了 REQUIRES_INSECURE_CHANNEL 屬性的請求都是從 HTTP發(fā)送過來的。如果沒有使用請求的協(xié)議，這兩個實(shí)現(xiàn)都會轉(zhuǎn)到 ChannelEntryPoint，而兩個 ChannelEntryPoint 實(shí)現(xiàn)所作的就是簡單的把請求相應(yīng)按照 HTTP 和 HTTPS重定向。 要注意重定向是絕對（例如 ） 而不是相對的 (例如 /app/page)。在測試中發(fā)現(xiàn) Inter Explorer 6 Service Pack 1 有一個 bug，因此如果在重定向的時候也改變使用的端口，它就不能正確響應(yīng)。對應(yīng)這個 bug，在很多 Acegi Security bean中都會使用的PortResolverImpl 也使用絕對 URL。請參閱 PortResolverImpl 的 JavaDoc以獲取更多信息。 你要注意使用為了在登錄過程中保證用戶名和密碼的安全，要使用安全信道。如果你配合基于表單的登錄使用 ChannelProcessingFilter，請記得一定要把你的登錄頁面設(shè)置為 REQUIRES_SECURE_CHANNEL，并且 屬性設(shè)置為 true。 . 結(jié)論 一旦配置好了，使用安全信道是非常簡單的。只要請求頁面，不用管使用什么協(xié)議（ HTTP 或 HTTPS）或什么端口（ 80, 8080, 443, 8443等）。顯然你只要確定初始請求 (獲取通過在 中的 或一個眾所周知的主頁 URL)，完成以后 filter會執(zhí)行你 application context 定義的重定向。 你也可以在 ChannelDecisionManagerImpl 中增加自己的ChannelProcessor實(shí)現(xiàn)。例如，你可能通過 輸入圖片中的內(nèi)容 檢測到一個個人類用戶，然后在 HttpSession中設(shè)置一個屬性。 要判斷一個安全檢查應(yīng)該是或者 ChannelProcessor或是 AccessDecisionVoter 記得前者是設(shè)計(jì)用來處理認(rèn)證或者未認(rèn)證的請求，而后者是設(shè)計(jì)用來處理已認(rèn)證的請求。因此后者可以訪問已認(rèn)證的 principal 被授予的權(quán)限。 另外， ChannelProcessor檢測到問題后一般是引發(fā)一個 HTTP/HTTPS重定向這樣他的請求可以被滿足，而 AccessDecisionVoter將則會跑出一個AccessDeniedException異 常 (取決于支配的 AccessDecisionManager)。 acegi參考手冊 ()[譯 ]第五章 標(biāo)簽庫 第五章 標(biāo)簽庫 . 概述 Acegi Security帶有若干個可以降低 JSP編寫難度的 JSP標(biāo)簽庫。標(biāo)簽庫的標(biāo)志是 authz，它提供了一些各不相同的服務(wù)。 . 配置 所有的標(biāo)簽庫類都包含在 文件中， JAR 的 METAINF目