Spring Security 簡介
連假有點閒, 來寫點自己最近在讀 source code 的體驗 (不讀書都在看 source code) XD
最近讀的是 Spring Security 的 source code，我覺得 Spring 在命名這些物件的時候都滿有意思的，也滿符合生活上的經驗。
Authentication and Access Control
大多數的系統使用者做完登入流程之後，後端都有者兩件事情要做，驗證身份 (Authentication)，跟限制使用者的存取權限 (Access Control)。
驗證身份，在有更高安全性考量下，Two-factor authentication 或是 Multi-factor authentication 是還蠻常見的驗證手續。
存取權限，這比較好懂，就是根據使用者的角色，決定使用者可以使用哪些功能，VIP 或是消費敏感者 XD，而這些資訊通常會跟著使用者的 Session 或 Token 在每個請求中流動。
驗證架構
在讀 Spring 原始碼的時候，不難看見 Manager (管理者)， Provider (供應者)，Delegate (代表、委派) 這些命名，但其實很好理解，Manager 就跟你公司高層的主管那樣只負責決策大方向 (出一張嘴) 他們通常都長得很像一個 interface，實作細節都交給 Provider 就是小小的工程師你 (實現大雄的願望吧)，Delegate 就是你做得很煩，把皮球踢給同事那樣…
Security 最主要核心我想應該是 AuthenticationManager，對，它是一個 interface，裡面只描述一件事就是 authenticate (認證)，而上圖看到的 ProviderManager 都是 AuthenticationManager 的實體 (實作)。
而認證流程是一串的驗證鏈子組成 (Provider Chain) ，不得不說 Chain pattern 在這邊被使用真的很合適。需要 Chain Pattern 是因為除了使用者的身份外，還有 Cross Domain， Container session(Tomcat, Jetty, etc.)， 還有 Spring 也提供了第三方 CAS SSO 的整合驗證，有現今流行的 OAuth 系列，SAML，Kerberos，etc。但不用太擔心，Spring 都有提供整合範例，如果你有認真地讀他的文件的話。
強大的 Providers，連 GoogleAccountAuthenticationProvider 都有，是不是好棒。
Framework 的 middleware
大多數的 Framework 都有規劃處理 HTTP 的 middleware，老牌的 Spring 也有，只是 Spring Framework 3.0 之前的都是透過 xml 做定義（XML 真的是視力殺手）。
當你定義好你的那些驗證 Providers，最後一步就是將他整合到 Filter 階段，當然你想把 Provider 的驗證在 AOP 裡面實作，也沒什麼不可以（什麼都要寫在 AOP，你全家都寫在 AOP 最棒了） 我也不清楚這樣做好不好？
我不寫在 AOP 是因為從 Client 到 AOP 已經經過 Servlet 的 Dispatch，我也不確定有沒有什麼資安疑慮，雖說 Spring 基本的 FilterComparator.java 會先幫你的 Request 做基本的驗證，我通常會按照 FilterComparator.java 的設計的順序去調整與 Overwrite，原則上我還是會比較頃向按照 Framwork 設計的精神將驗證整合在 Filter 階段。
Access Control
存取的控制，就自由多了，基本上是透過 GrantedAuthority.java ，透過實作這個 interface 可以簡單地制定 Role，這就看需求了。
Method Security
同時 Spring Security 也提供了類似 AOP Security 的機制，就是在 methods 執行階段檢查使用者的 Access Control，但我目前沒有想到比較好的使用情境，大概是類似有個 abstract method 會依據 Role 給出不同的結果之類的，這個設計在講求 SOLID 精神是個不錯的設計，必須 extends Abstract class 去做這件事，但在講求速度就是一切的文化裡，其實只是一個 switch case 就解決了… 所以我也很少用這個部份。
整個過程其實我看很久，參考了許多人的文章，但把知識整理抽象之後，發現自己寫的也很抽象，有機會再來談 Legacy security xml 的痛苦吧。
