首先描述最簡單的身份驗證后臺的處理過程
1、 用戶輸入需要確認自己身份的信息，如賬號與密碼或許需要其它信息
2、 也許你希望提供多種有方式的驗證形式，由系統選擇最合適的那一種，如從數據庫(DAO)或是通過身份驗證中心的服務(ACS)統一管理等
3、 根據賬號找到指定源中的用戶、密碼及所擁有的權限(如果沒找到就拋出異常)等用戶的身份信息，驗證用戶輸入的信息與源中返回的信息是否一致(如密碼)
4、 為了不至于每次都重復上面的過程，還要將驗證后的信息緩存起來，如放到session中
與acegi結合分析
1、 用戶提交后為了能進行上述的處理，acegi不是通過請求-影響模式，而是能過Servlet的Filter實現的。可以理解成這個身份驗證的主入口，不同的處理機制采用不同的Filter,類名的規則為*ProcessingFilter，這些類全部都繼承至javax.servlet.Filter接口。下面是幾個常用的過濾器
|
模塊
|
功能
|
|
BasicProcessingFilter
|
按照RFC1945處理基本的身份驗證請求
|
|
CasProcessingFilter
|
處理耶魯大學的中心身份驗證服務器(CAS)許可
|
|
AnonymousProcessingFilter
|
對匿名身份的處理
|
|
AuthenticationProcessingFilter
|
處理類似于Servlet規范的j_security_check的Http form post
|
在Spring的配置過程中有些過濾器除了自身的信息外，還有可能需要切入點，以便切入到其它模塊中的配置信息。如AuthenticationProcessingFilter驗證不通過的處理頁面或要采用的協議、CasProcessingFilter需要提交到CAS上的其他信息。它們的統一接口類為AuthenticationEntryPoint在此要注意的是，切入點與過濾器之間有著密切的聯系與對應關系的。
2、 acegi為了實現多種方式的驗證形式提供了AuthenticationManager接口，目的是對多種驗證形式進行管理，并通過指定的驗證形式返回用戶的身份。所以上述的過濾器均會調用該接口的authenticate(Authentication authentication)方法以返回當前用戶的身份信息。該接口主要的實現類是ProviderManager
AuthenticationProvider(身份驗證供應器)接口有很多實現類，每個都致力于處理一個特定身份驗證的具體實現，AuthenticationManager負責輪詢AuthenticationProvider列表，并使用第一個能夠處理給定的Authentication請求對象的AuthenticationProvider。身份驗證供應器也就是上面說的驗證形式。最常用的是DaoAuthenticationProvider，實現從數據庫中獲取用戶的身份信息
3、 在acegi中用戶的身份信息存放到以Authentication接口的實現類的實例中。在介紹該接口之前先要了解一些關鍵術語
1） principal(主體)指可以執行操作的用戶、服務或代理(agent)，即身份驗證的發啟者
2） credential(憑證)指主體提供密碼之類用于身份驗證(authentication)的信息戳
3） authentication(身份驗證)確定調用者身份的過程
4） authorization(授權)指決定哪個主體準許執行給定操作的過程
Authentication接口包含主體標示、主體的憑證以及主體所擁有的一組權限。
Authentication接口繼承java.security.Principal接口，因此Authentication天生就要滿足主體的類型。該接口實際上是上述幾個關鍵詞對象化的一個容器，它存儲了身份驗證的全部信息。由此會發現它與AuthenticationProvider(身份驗證供應器)有著天然的聯系，如對于數據庫的供應器它只要記錄用戶的帳號和密碼，但對于CAS它還可能還要記錄服務器響應的列表，或是與認證相關的其它信息。因此該接口對應身份驗證供應器有多個實現類。正因為于此，所有的實現類對于開發者來說幾乎是隱藏在，可以理解成工具或是服務類
下面對Authentication接口中的方法做詳細擴展說明
1） getPrincipal(獲得主體)與getCredential(獲得憑證)，它們的設置過程：無論何種驗證形式用戶都是通過用戶輸入帳號和密碼開始的，過濾器會攔截用戶的請求，由驗證管理器(AuthenticationManager)找到合適的身份驗證供應器(AuthenticationProvider)提供身份驗證。在AuthenticationManager接口只有一個方法authenticate(…),而該方法的參數與返回類型均是Authentication。所以大多數過濾器在請求身份驗證前總是創建一個簡單的UsernamePasswordAuthenticationToken(該類是Authentication接口的子類)對象，將其作為AuthenticationManager.authenticate(…)方法中的參數，再由AuthenticationProvider依據自身的特點創建相應的Authentication接口子類的實例，因此身份驗證的具體信息也是在這最后一步完成的，即是在AuthenticationProvider中被創建與賦值的。其中就包括主體與憑證。如對于數據庫來說也是賬號與密碼。
2） getAuthorities()得到當前用戶所擁有的全部權限。Acegi提供一個GrantedAuthority接口，用于對應應用系統中有真正意義的權限實現。常用的是GrantedAuthorityImpl,它存儲主體的已獲授權的String表示，即權限也就是字符串的表示。而GrantedAuthority僅對字符做一層簡單的封裝。
3） getDetails()獲取詳細資料，目的是得到當前用戶的詳細信息，如在應用系統可以是用戶的一個Bean(所在的部門,真實姓名…)。為此Acegi提供了一個UserDetails接口.
l
isAccountNonExpired 帳號是否未過期
l
isAccountNonLocked 帳號是否未鎖定
l
isCredentialsNonExpired密碼是否未過期
l
isEnabled 是否可用(激活)
我們會發現對于一個應用系統來說，用戶的詳細信息中除與身份驗證相關的信息外還要很多其它的信息，如用戶所在的部門、電話…。為此acegi提供了另一個接口AuthenticationDetailsSource,它僅提供一個方法buildDetails(HttpServletRequest
request)用以創建客戶化的用戶信息。在過濾器中在執行身份驗證之前調用該方法。
4） isAuthenticated()，是否通過了身份驗證
當通過主體(帳號)從源(如DAO、CAS、JAAS…)中返回的信息中創建出Authentication實例后，還要校驗用戶的憑證(密碼)的一致性。對于提供了以PasswordEncoder接口為代表的一組密碼編碼器的實現
4、 在我們討論對于身份驗證(Authentication)對象的保存之前，先來說明一下對它的訪問。為了確保任何對身份驗證感興趣的類型都可以訪問它，acegi通過SecurityContextHolder(該類中提供的所有成員方法均是靜態的)用來保持SecurityContext的ThreadLocal對象。
通過SecurityContext類圖可以看出在它很簡單只是對Authentication對象的一個引用，之所以又做了這樣一層包裝的目的是為了客戶可以做任意的擴展。由于SecurityContextHolder引用的是線程ThreadLocal集合，而對于B/S系統來說，一個線程的生命期還是太短了，無法保證SecurityContext對象的信息在一個線程執行后不會被JVM垃圾回收。一般來說我們會將SecurityContext放到session中，但這樣又無法保證在邏輯層中訪問到session。對此acegi的解決方案是通過javax.servlet.Filter使不同與的訪問范圍與SecurityContextHolder做整合(以session為例，每次請求過濾器都會從session中取得SecurityContext然后再將其賦到SecurityContextHolder)。Acegi提供了多種整合過濾器，命名規則為*IntegrationFilter
|
模塊
|
功能
|
|
HttpSessionContextIntegrationFilter
|
請求之間使用HttpSession存儲SecurityContext
|
|
HttpRequestIntegrationFilter
|
從HttpServletRequest.getUserPrincipal()獲得身份驗證，但在請求結束時不能將該身份驗證寫回該位置
|
|
JbossIntegrationFilter
|
從Jboss的java:comp/env/security/subject的JNDI位置獲取身份驗證，但在請求結束時不能將該身份驗證寫回該位置
|
接下來再來討論對Authentication的設置，當處理過濾器調用AuthenticationManager. Authentication(…)獲得Authentication對象后，它會調用自身的成員方法successfulAuthentication(…)將其封裝為SecurityContext并設置到SecurityContextHolder中。
注意successfulAuthentication(…)方法是在抽象類AbstractProcessingFilter中，而有一些處理過程器并沒有繼承該類，所以只有AbstractProcessingFilter的子類才會在當前線程中取得SecurityContext對象。
再來描述授權的后臺的處理過程
1、 我們可能希望在三個地方做安全驗證，即是否可以訪問當前頁面，是否可以調用當前方法，是否可以控制當前方法參數的對象域
2、 對于安全驗證的判斷可能希望提供不同的表決策略，如一票否決制，還是有一票同意就通過或是同意大于否決票時才通過。
3、 總之，所有需要的處理無非是在做這樣的工作。當前用戶所擁有的權限中，否則有（或匹配）與當前被調用者(頁面、方法、域)所指定的權限
Acegi對于授權的技術實現
從技術上話，授權完全與日志一樣是一個橫切關注點，與具體業務沒有任何關系。而Acegi只是借助Spring的AOP與javax.servlet.Filter，對這授權方面的攔截。對于攔截器與其持有的對象Acegi提供如下實現：
|
攔截器
|
描述
|
持有的對象
|
描述
|
|
AbstractSecurityInterceptor
|
是所有攔截器的抽象父類，實際授權的全部驗證過程均在該類beforeInvocation()與afterInvocation()兩個方法中完成，子類只是區別不同類型的安全對象。
|
|
FilterSecurityInterceptor
|
是一個web的過濾器，用于對頁面(URL)的授權驗證
|
FilterInvocation
|
僅是對簡單crequest、response與FilterChain包裝的實現
|
|
MethodSecurityInterceptor
|
用于驗證Spring容器中bean的方法，并且需要使用Spring中的代理
|
MethodInvocation
|
AOP Alliance提供的被代理對象接口,運行時的實際對象類型是由Spring提供的ReflectiveMethodInvocation或CglibMethodInvocation
|
|
AspectJSecurityInterceptor
|
該類是在指定切入點調用AspectJ
|
JoinPoint AspectJCallback
|
執行AspectJ的回調
|
|
|
|
|
|
AbstractSecurityInterceptor的執行過程：
首先查詢應用于該調用的配置屬性。如果沒有任何配置屬性，該調用被認為是公有的，并且繼續進行該調用。如果找到配置屬性，包含在SecurityContextHolder中的Authentication是通過AuthenticationManager驗證的，并且請求AccessDecisionManager來批準該請求，如果成功RunAsManager可以替代該Authentication的標識，然后繼續進行該調用。調用完成時，將通過更新SecurityContextHolder來包含實際的身份驗證對象以清除RunAsManager的替代標識。最后調用AfterInvocationManager，如果定義了的話。
RunAsManager：該接口的主要作用成員方法是Authentication
buildRunAs(Authentication authentication, Object object,
ConfigAttributeDefinition config)目的是當執行特定操作時用于選擇性的替換Authentication對象，該方法是在安全驗證之后，安全對象執行之前被調用。在安全對象執行之后該方法對Authentication對象替換后被還原。
AfterInvocationManager:作用是修改從安全對象調用中返回的對象。這通常被用來過濾僅針對已包含、已驗證元素的集合，或者如果信息是受保護的，轉換實例變量。如果該主體沒有針對返回對象的權限，它還可以拋出AccessDeniedException。主要的方法是
Object decide(Authentication
authentication, Object object, ConfigAttributeDefinition config, Object returnedObject) throws
AccessDeniedException，它需要返回一個對象，然后該對象將變成安全對象調用的結果。輪詢AfterInvocationProvider接口的具體類。
最后分析權限表決的原理，還是讓我們虛擬這樣一個場景：
1、 要求有兩個表決器，1）判斷當前用戶是否為超級管理員,2)判斷當前用戶是否擁有當前所調用的方法或頁面的權限
2、 如果其中任何一個表決器投出贊成票，就認為通過。這是一種表決策略
與Acegi結合分析
2、表決策略作用是輪詢所有的表決器，根據當前策略結合表決器的表決結果，做出最終判斷結果。Acegi表決策略管理的接口是
1) decide(…)根據當前用戶所擁有的權限信息[authentication],攔截器所持有的對象[object]以及在配置文件中所持有對象所必要的權限s[config],輪詢表決器做出決策。
2) supports(ConfigAttribute)判斷所有表決器是否有一個以上支持這種權限的表示形式
3) supports(Class) 判斷所有表決器是否有一個以上支持攔截器所持有的對象類型
后兩個方法主要在是各種攔截器初始化時調用，以但Spring驗證bean定義的合法性
對于表決策略來說最終可能會得到三個結果中的一個贊成、否決或是棄權（結果是由表決器結合策略得到的）。對于棄權的產生是由于攔截器所持有的對象在配置中沒有設置任何權限。為此該接口的抽象子類提供allowIfAllAbstainDecisions開關,如果所有表決器投出的均為棄權票，表示沒有通過授權則將該屬性設為true，默認為false.
Acegi提供了多種表決策略
注意：一個表決器只能投一票
AffirmativeBased 有一個決策器投出贊成票就通過
ConsensusBased 贊成票大于否決票就通過,相同也算是沒有通過授權
UnanimousBased 一票否決制,也就是只要有一個表決器投否決票就算不通過
因此對于上面的場景我們應該選擇AffirmativeBased表決策略，在決策略下還要有兩個表決器，下面介紹表決器
1、