spring security翻譯

1. 第一步就是建立java配置，配置就是建立一個Servlet Filter，也就是springSecurityFilterChain，它負責處理應用中的全部spring security事物（保護url，驗證用戶名密碼，重定向到登陸表單）。
   
   configureGlobal方法名不重要，重要的是須要在有@EnableWebSecurity、@EnableGlobalMethodSecurity、@EnableGlobalAuthentication等註解的類下配置AuthenticationManagerBuilder，不然致使不可預知的結果。
   上面這個配置看起來沒多少，可是作的工做卻不少，以下：
1. 要求認證每個url
2. 爲你生成一個登陸表單
3. 容許用戶經過user、password來經過驗證
4. 容許用戶登出
5. 防止CSRF攻擊
6. 固定Session保護
7. 集成Security Header
8. 集成Servlet API method
2. 第二步註冊springSecurityFilterChain，這個在servlet 3.0環境下能夠經過Spring's WebApplicationInitializer support來作java配置。固然，Spring Security提供了一個基類AbstractSecurityWebApplicationInitializer，它將保證springSecurityChain被註冊。可是使用AbstractSecurityWebApplicationInitializer的時候要分兩種狀況：
1. 項目中沒有使用到springMVC或Spring而想用SpringSecurity的話，你須要傳遞Security Config到父類中，來保證配置被加載。以下：
   
   這裏作了如下事情：
1. 自動註冊springSecurityFilterChain Filter
2. 添加ContextLoadListener來加載Security Config
2. 若是已經使用了springMVC，咱們只須要這樣：
3. 到如今咱們的Spring Security只知道如何去驗證用戶，那麼如何讓它知道咱們須要驗證全部用戶呢？如何讓它知道咱們須要基於表單的驗證呢？這個問題在於WebSecurityConfigurerAdapter的configure方法中，它提供了一個HttpSecurity來幫助咱們配置相應需求：
   
   默認的配置以下：
1. 保證到應用的請求都必須被驗證
2. 容許用戶經過基於表單的登陸驗證
3. 容許用戶驗證Http的基本驗證
4. 要注意這裏的and（）方法，它讓咱們能夠更好的配置http，看源碼就能夠知道。
4. 能夠注意到登陸表單是從哪來的，由於尚未提到過任何html或jsp呢，因爲spring Security的默認配置沒有明確地爲登陸頁面設置url，spring Security會自動生成一個，可是通常是自定義的登陸界面，那麼能夠經過controller來指向它：
   
5. 咱們如今只是要求用戶被驗證，而且每個url也被驗證。咱們能夠指定爲url子目錄添加特別的需求：
   
   如上就是爲http提供了多個子驗證模塊
6. 結構和實現
1. 核心組件：
2. SecurityContextHolder--這是最基本的對象，咱們在這裏存儲應用的Security Context，包涵了應用中用戶的安全驗證細節。SecurityContextHolder默認使用ThreadLocal（使得每個線程保持各自獨立的對象，經過set來設置，get來獲取）來存儲這些細節，這就意味着在該線程中，security context能夠被每個方法訪問到，即便Security contex沒有做爲參數被明確傳遞給該方法。這樣但處理完request的時候，清空線程也會是安全的，固然這都不須要使用者來關心。可是有些應用不太適合用ThreadLocal，由於它們有特定的使用線程方式，好比一個Swing的客戶端須要讓JVM中的全部線程使用相同的Security context。啓動時，能夠經過策略來指定你須要的SecurityContextHolder存儲方式。然而大多數狀況下，咱們是不須要修改默認存儲策略的。
3. Authentication--在SecurityContextHolder中咱們存儲的是和應用用戶交互的信息，spring security使用一個Authentication對象來表述這信息，你不須要本身建立這個對象，可是你常常須要查看這個對象，你能夠在你的應用中使用下面這段代碼來獲取當前被認證的用戶：
   
   這個對象能夠經過調用SecurityContext的getContext（）來獲取，這個對象是放在threadlocal裏面的。
4. UserDetailsService--從上面一段代碼中，還有一點值得咱們注意的是Authentication中包涵了用戶，這個用戶是一個Object類型，大多數狀況下這個類能夠被強轉成UserDetails對象，UserDetails是spring security的核心接口UserDetails，它表述的是一個用戶信息，可是是可擴展的而且是基於應用特定的。將UserDetails看做是一個數據庫適配器，spring security想要從SecurityContextHolder中獲取什麼信息，就找UserDetails就好了，做爲一個用戶數據庫，你通常會將UserDetails再次強轉成你的用戶對象，這樣你就能夠調用特定的業務方法，如：getEmail（），getUserId（）等等。
   如今，你可能會疑惑，何時提供UserDetails呢，我怎麼提供呢，答案就是UserDetailsService，這個接口有一個惟一的方法就是經過獲取一個用戶名字符串參數來返回UserDetails：
   
   這個是在spring security中獲取用戶信息最經常使用的方法。
   一旦成功驗證用戶，那麼UserDetails就會被用於在SecurityContextHolder中建立一個Authentication對象，好消息是咱們已經有了一系列的UserDetailsService實現類，包括使用了內存map（InMemoryDaoImpl）和使用JDBC的（JdbcDaoImpl），有不少人喜歡用他們本身的實現類，他們本身的實現其實也只基於他們本身的用戶系統而已，
5. GrantedAuthority--除了用戶信息，Authentication還有一個重要的方法getAuthorities（），它用來提供一個GrantedAuthority對象數組，GrantedAuthority是受權給用戶的權限，也被叫作角色
7. 認證
1. spring security到底幹了什麼
1. 保證用戶操做是登陸過的
2. 用戶名密碼是正確的
3. 用戶的上下問信息是被包涵的
4. 用戶的安全上下文是被建立的
5. 權限是被授予的
2. 如今咱們來複現一下認證過程：
1. 你訪問一個網站的首頁，點擊鏈接
2. 請求發送到服務器，服務器發現這是個被保護的資源
3. 因爲你沒有被受權，服務器須要將你沒有權限的信息返回給你，能夠http的錯誤信息，也能夠是自定義的錯誤頁面
4. 根據驗證機制，你的瀏覽器會重定向到一個登陸頁面以便你完成登陸信息填寫，或者瀏覽器會直接填寫你的表單（cookie）
5. 瀏覽器再次發送給服務器，信息既能夠是用戶POST的表單信息，也能夠是包涵你驗證細節的http頭部
6. 而後服務器會檢測當前驗證信息是否正確，若是正確，會進入第7步，若是錯誤，通常會返回錯誤信息以便再次填寫表單
7. 會再次請求你最開的鏈接，若是你的足夠的權限來訪問到這個資源，那麼請求成功，若是沒有，你會收到403錯誤信息
3. 上面順序的絕大部分spring security都提供了相應的類來對應處理，主要有ExceptionTranslationFilter，AuthenticationEntryPoint和AuthenticationManager的驗證機制。
1. ExceptionTranslationFilter--是一個spring security的過濾器，用來檢測spring security的任何異常拋出，異常主要由AbstractSecurityInterceptor拋出，它是驗證服務的主要提供者。
2. AuthenticationEntryPoint--是認證過程當中的第三步，每一個應用都會提供它本身的認證機制，那麼每個認證機制有他們本身的AuthenticationEntryPoint實現。
3. 認證機制--一旦你的瀏覽器提交你的認證信息，也就是第六步，當驗證機制取回全部Authentication對象，若是驗證成功，會將Authentication對象放入SecurityContextHolder，而後再次啓動源請求，不然AuthenticationManager拒絕請求，驗證機制會向瀏覽器要求再次發送認證信息
4. 在請求中間存儲SecurityContext，略
8. 本地化
1. spring security支持異常信息的本地化，以便用戶更好地理解，若是你的應用是爲英語用戶提供的，那就不須要了。
2. 全部的異常信息均可以被本地化，包括認證失敗和受權失敗，異常和日誌信息
9. 核心服務
1. AuthenticationManager--是一個接口，咱們能夠實現任何咱們想作的事，實際上如何操做？若是咱們須要檢查多個驗證數據庫呢？默認實現是ProviderManager，比起本身處理認證請求，它將這部分工做移交給了一系列的AuthencationProvider，每個都會被用於驗證，每個Provider均可拋出異常，也能夠返回一個徹底填充的Authencation對象，還記的UserDetails和UserDetailsService嗎？若是不記得就返回去看看。驗證請求最一般的作法就是獲取到相應的UserDetails並檢查獲取到的密碼和用戶輸入的密碼，這就是AuthencationProvider的作法，而UserDetails對象和他的權限組會被徹底填充到Authencation對象中，並保存在SecurityContext中。若是是基於namespace的配置，能夠以下：
   
   在這裏，咱們提供了3個Provider，他們會按顯示的順序來驗證，若是或者經過return null 來跳過驗證，若是全部Provider都返回null，那麼ProviderManager會返回一個ProviderNotFoundException，大家能夠到ProviderManager的JavaDoc中查看更詳細的關於provider chain的信息。
2. ProviderManager--驗證機制會在filter會注入一個ProviderManager的引用，並調用它來驗證請求。你須要的provider是能夠互換的，默認地，spring security會經過ProviderManager來清空Authencation對象中任何敏感的認證信息，防止像密碼這樣的信息存在的時間大於它可做用的時間。這樣作會帶來一個問題：若是在Authencation中使用了緩存，緩存中有UserDetails對象的引用，那麼移除它的認證信息，那麼這個對象就不能再次驗證對象中的緩存了，你須要將它複製一份到你的緩存中。還有一種辦法就是ProviderManager.eraseCredentialsAfterAuthentication（）設爲false
3. DaoAuthenticationProvider--這是spring security提供的AuthencationProvider接口最簡單的實現類，也是被最容易被框架兼容的。它利用一個UserDetailsService（做爲DAO）來查找用戶名，密碼，權限組，它只是簡單地驗證從用戶提交信息中包裝成的UsernamePasswordAuthenticaionToken中的密碼和UserDetailsService中的密碼，配置也很簡單：
4. UserDetailsService--上面已經提到過，全部Provider都要用到UserDetailsService接口和UserDetails，UserDetailsService中只有惟一的一個方法，就是UserDetails loadUserByUsername(String username) throws UsernameNotFoundException。
5. In-Memory Authentication--用來建立一個自定義的UserDetailsService實現類，選擇從持久層獲取信息，可是大多數應用無需這麼複雜。
6. JdbcDaoImpl--spring security也包括一個從jdbc數據源來認證的UserDetailsService，內部使用了springJDBC，就避免了複雜的ORM來存儲用戶信息，若是你的應用用到了ORM工具，你就須要本身來實現UserDetailsService來重用或許已經建立好的映射文件：
   
   經過修改DriverManagerDataSource信息，你可使用不一樣的關係數據庫。
7. 密碼編碼
1. spring security的PasswordEncoding接口用來支持持久化密碼時的編碼工做，咱們毫不應該直接將原文密碼直接持久化，通常都是利用單向哈希算法（將任意長度的二進制值映射成一個固定長度的二進制值，這個小的二進制值被稱爲哈希值，它是一段數據的惟一表現形式，要找到兩個散列爲同一個值的輸入，在計算上幾乎不可能，因此它能夠用來快速查找和加密），如bcrypt，