授權(quán)系統(tǒng)源碼-（十）SpringSecurity授權(quán)和鑒權(quán)原理

1、_SpringSecurity授權(quán)和鑒權(quán)原理、SpringSecurity框架中的授權(quán)源碼分析個完整的權(quán)限系統(tǒng)總體上來說可以分為兩個：1、認(rèn)證（Authentication）2、授權(quán)（Authorization）上篇章中我們已經(jīng)定義了認(rèn)證流程的架，實現(xiàn)了讓框架幫我們管理會話以及持久化登錄信息到Session的功能。不過默認(rèn)情況下，所有戶對于所有url，只需要登錄就能夠訪問，這可不是我們想要的。個完整的系統(tǒng)，應(yīng)該將戶以某種維度進(jìn)分類，不同的戶具有不同的權(quán)限，從能夠訪問不同的URL。所以授權(quán)的關(guān)注點主要有兩個：1、戶和權(quán)限的映射2、權(quán)限和Url的映射1和2結(jié)合最終實現(xiàn)戶和可訪問的Url的映射回顧上

2、節(jié)的的定義配置中有這么段代碼：要想了解SpringSecurity是如何進(jìn)授權(quán)的，就從這段代碼。landexiang：（）從框架設(shè)計的度來看springSecurityFilterC1、繼承結(jié)構(gòu)從類圖上可以直觀的發(fā)現(xiàn)，授權(quán)配置相關(guān)功能也是個很復(fù)雜設(shè)計。有的讀者可能沒看過類圖，這稍微解釋下：紅的線表內(nèi)部類，藍(lán)箭頭表繼承，實線箭頭表組合關(guān)系（可以理解為A有個屬性為B，B作為A這個整體的部分），虛線表依賴關(guān)系，圖上的依賴關(guān)系體現(xiàn)為創(chuàng)建關(guān)系（如A中new了類型為B的對象）。1.1 授權(quán)相關(guān)的ConfigurerConfigurer指的就是SecurityConfigurer，Registry是Conf

3、igurer的內(nèi)部定義，具體是什么請請繼續(xù)往后看。AbstractHTTPConfigurer就不了解了，HttpSecurity中使的SecurityConfigurer乎都繼承于這個抽象類，提供了兩個輔助性的功能，其最主要的功能還是體現(xiàn)在語義層次上，即表類是服務(wù)于HttpSecurity的。所以圖上的類我們從AbstractInterceptUrlConfigurer開始著。 。先來看下這個抽象類的注釋：從注釋中可以了解到AbstractInterceptUrlConfigurer主要是給FilterSecurityInterceptor、其他的SecurityConfigurer的sha

4、redObject、AuthenticationManager提供持。AbstractInterceptUrlConfigurer有兩個實現(xiàn)類從HttpSecurity的配置可以看出，框架中默認(rèn)使的實現(xiàn)類通過注釋可以了解到ExpressURLAuthorizationConfigurer在抽象類AbstractInterceptUrlConfigurer的基礎(chǔ)之上額外提供了基于SPEL表達(dá)式的授權(quán)功能，并且少有個RequestMapping注解所代表的url映射到個ConfigAttribute，ExpressURLAuthorizationConfigurer才有意義。從注釋中可以了解到兩個

5、信息：1、SpringSecurity框架默認(rèn)是使SPEL表達(dá)式來對URL進(jìn)授權(quán)的2、ConfigAttribute對象和RequestMapping映射的URL有定聯(lián)系另外可以發(fā)現(xiàn)ExpressURLAuthorizationConfigurer中還有個內(nèi)部類，些是的，些是定義在抽象類的。1.2 授權(quán)相關(guān)的Registry從類圖上來看，registry的頂級類為抽象從注釋來看主要是來注冊RequestMatcher類，RequestMatcher的提供了url匹配的功能，包括請求法，請求路徑等匹配式。AbstractConfigAttributeRequestMatcherRegistry作

6、為AbstractRequestMatcherRegistry的抽象類，在類功能的基礎(chǔ)之上，額外提供了UrlMapping和ConfigAttribute相關(guān)的操作。如下圖所前已經(jīng)提到過ExpressURLAuthorizationConfigurer注釋表明RequestMapping映射的url和ConfigAttribute有定的聯(lián)系，從這就可以得出結(jié)論，對于已授權(quán)的url會被封裝成個UrlMapping對象，其中既包含了匹配url的RequestMatcher對象包含了表url權(quán)限信息的ConfigAttribute對象，不過前只是猜測，具體是不是還要繼續(xù)看源碼。抽象類Abstract

7、InterceptUrlRegistry繼承于AbstractConfigAttributeRequestMatcherRegistry，定義在抽象配置類AbstractInterceptUrlConfigurer中從代碼中可以看出AbstractInterceptUrlRegistry提供了AccessDecisionManager類的set功能。AccessDecisionManager提供了請求鑒權(quán)的功能。ExpressionInterceptUrlRegistry繼承于AbstractInterceptUrlRegistry，從源碼看，除了具有類特性外，提供了兩個功能1、創(chuàng)建請求的ur

8、l授權(quán)的結(jié)果類AuthorizatedUrl和MvcMatchersAuthorizedUrl2、設(shè)置處理SPEL表達(dá)式的handler從源碼來看，每個類所提供的功能都較簡單，但是由于繼承鏈較長和復(fù)雜，所以理解起來還是會有些晦澀。所以下就來從框架實際的運(yùn)來進(jìn)源碼解析。2、SecurityConfigurer的構(gòu)造函數(shù)分析個SecurityConfigurer到底做了哪些事，在粗略了解了相關(guān)類的繼承結(jié)構(gòu)之后，先應(yīng)該看得是構(gòu)造函數(shù)。在構(gòu)造函數(shù)中創(chuàng)建了ExpressionInterceptUrlRegistry對象，這個registry的功能在前已經(jīng)簡單敘述到了。不過有點需要注意：在HttpSecu

9、rity對象中設(shè)置授權(quán)相關(guān)配置時，創(chuàng)建了ExpressionUrlAuthorizationConfigurer配置后，返回值是ExpressionInterceptUrlRegistry，也就是authorizeRequests()法的返回值是ExpressionInterceptUrlRegistry，所以后的.anyRequest().authenticated()都是對于ExpressionInterceptUrlRegistry的設(shè)置。剛好通過這個設(shè)置來看下Registry相關(guān)類的詳細(xì)功能：ANY_REQUEST表個matches始終返回true的RequestMatcher類，也就

10、是匹配任何url。requestMatchers法，chainRequstMatchers是抽象實現(xiàn)的。chainRequestMatcherInternal則是類ExpressionUrlAuthorizationConfigurer中實現(xiàn)的，最終創(chuàng)建了個AuthorizedUrl對象：所以.anyRequests()法的返回值為AuthorizedUrl，后的authenticated()是AuthorizedUrl提供的法。從注釋來看AuthorizedUrl.authenticated法的功能為指定當(dāng)前對象中所有requestMatchers所能匹配的url對于所有已認(rèn)證的戶開放。從源

11、碼來看，SpringSecurity框架是將表匹配所有請求是AnyRequestMatcher和表已認(rèn)證權(quán)限的authenticated字符串作為們在上根據(jù)類的注釋信息推測出的結(jié)果致。且從源碼的屬性定義來看，SpringSecurity的權(quán)限應(yīng)該有固定的6種。通過上的源碼分析，我們可以知道的是對于Url的訪問權(quán)限設(shè)置是AuthorizedUrl的作，AuthorizedUrl是在AbstractRequestMatcherRegistry抽象類中創(chuàng)建的。如果我們想給url進(jìn)權(quán)限細(xì)化，則還需要看下這個類中還提供了哪些法：從源碼中可以看出還有額外的三種url映射設(shè)置式，不過url匹配使的都是ant

12、風(fēng)格的表達(dá)式。這三種設(shè)置分別是：1、固定請求法，但匹配所有url的AuthorizedUrl2、固定請求法，固定url的AuthorizedUrl3、只固定url的AuthorizedUrl且1其實就是使2來進(jìn)創(chuàng)建的。現(xiàn)在我們已經(jīng)知道了使antMatchers()法就可以定義攔截Url創(chuàng)建AuthorizedUrl，但是授權(quán)除了authenticated，還有哪些式呢？當(dāng)然是來看下AuthorizedUrl還提供了哪些授權(quán)法。not表不具有xxx權(quán)限上種是框架提供的默認(rèn)權(quán)限，同來進(jìn)粗粒度的授權(quán)作可以發(fā)現(xiàn)框架中除了提供可選的6種默認(rèn)權(quán)限之外，還提供了兩種定義的設(shè)置式：1、hasRole2、has

13、Authority通過源碼可以看出，其實返回的就是個SPEL表達(dá)式，role和authority的不同之處在于如果使hasRole則表使的是url，注冊時不能帶ROLE_前綴，框架會給你動補(bǔ)上這個前綴。使authority表使的是url權(quán)限，則沒有任何限制。也就是說通過框架提供的這種特性我們可以對于同個url進(jìn)兩種授權(quán)設(shè)置，種基于，種基于權(quán)限。如我們想設(shè)置/user所有路徑必須具有ROLE_USER或者M(jìn)ODEL_USER_REQUEST權(quán)限才能進(jìn)訪問則可以像下這樣設(shè)置：2、SecurityConfigurer的init法通過上的源碼分析，我們已經(jīng)知道了如何使框架提供的功能去定義url授權(quán)，但

14、是我們?nèi)圆涣私饪蚣苁侨绾舞b權(quán)的。所以還需要繼續(xù)看下相關(guān)的源碼，才能夠進(jìn)我們的權(quán)限系統(tǒng)的設(shè)計。之前的章中已經(jīng)介紹了SpringSecurity的基本設(shè)計模式，所以SecurityConfigurer的init法是我們閱讀源碼時必須了解的。但是通過源碼可以看到ExpressURLAuthorizationConfigurer以及其所有類都沒有重寫init法，根據(jù)init法的初衷，可以知道ExpressURLAuthorizationConfigurer是個功能相對較獨的模塊，因為他沒有經(jīng)過init法設(shè)置共享變量。3、SecurityConfigurer的configure法init法是來設(shè)置共享變

15、量到SecurityBuilder中的，configure法則是來處理SecurityBuilder的直接屬性。metadataSource是之后來鑒權(quán)的的元數(shù)據(jù)，可以看下他有哪些數(shù)據(jù)，了解下鑒權(quán)需要到的信息：從源碼來看，metadataSource中只有個處理SPEL表達(dá)式的handler和我們授權(quán)的url的信息。不過從源碼來看，如果設(shè)置了多個相同的RequestMatcher，只有最后的會效，前設(shè)置的會被覆蓋掉，所以我們設(shè)想的給同個url即授予授予權(quán)限是在默認(rèn)情況下是不通了如圖所，我們定義了三個antMatcher，但最終元數(shù)據(jù)中只有兩條，因為有兩個requestMatcher重復(fù)了。co

16、nfigure中只有這個需要特別關(guān)注，下就是創(chuàng)建filter了，沒什么特別的地。、SpringSecurity中的鑒權(quán)源碼分析通過上的個關(guān)鍵點，現(xiàn)在我們已經(jīng)知道如何定義url的授權(quán)，也知道了我們定義的授權(quán)哪些是有效的，最終的鑒權(quán)則是FilterSecurityInterceptor來完成的。 。FilterSecurityInterceptor作為個filter，所以鑒權(quán)相關(guān)肯定是在doFilter法中進(jìn)的。從源碼來看對于同個請求只需要鑒權(quán)次，所以對于請求的轉(zhuǎn)發(fā)，是不是可以越權(quán)訪問呢？上搜了下，好像沒發(fā)現(xiàn)相關(guān)資料，因為請求的轉(zhuǎn)發(fā)還算做同次請求，所以我也是猜測，以后抽空測驗下。鑒權(quán)操作主要是類來

17、做的，核代碼只有這。authenticated是我們的登錄信息，attributes則是從metadataSource中取出當(dāng)前訪問url所需要的權(quán)限信息：如我們訪問根錄/，則對應(yīng)著authenticated這條權(quán)限。如果沒有找到匹配當(dāng)前訪問url的授權(quán)定義，默認(rèn)情況下不做攔截。不過這有點需要我們注意我們來看下attributes是如何取出來的：權(quán)效所以下的定義是錯誤的正確的定義式應(yīng)該是：將anyRequest的授權(quán)放在最后?？蚣苤泄捕x了三種decisionManager。我們還是先了解下框架默認(rèn)為是否滿我們的需求：從注釋來看AffirmativeBased的鑒權(quán)其實是委托給AccessDe

18、cisionVoter來做的，并且只要其內(nèi)部的任意個AccessDecisionVoter鑒權(quán)通過，則算作當(dāng)前請求有權(quán)限訪問。框架中雖然定義了很多voter，但默認(rèn)到的只有個，即WebExpressionVoter。我們定義的SPEL表達(dá)式權(quán)限就是交給這個voter進(jìn)鑒定的，鑒權(quán)法為vote：WebExpressionVoter鑒權(quán)有三種結(jié)果：棄權(quán)，肯定，否定。當(dāng)返回肯定的時候則表鑒權(quán)通過，當(dāng)返回棄權(quán)和否定的時候，將鑒權(quán)交給下個voter進(jìn)。WebExpressionVoter最主要的鑒權(quán)是上這段代碼，即將戶的登陸信息中的權(quán)限和SPEL表達(dá)式進(jìn)對：鑒權(quán)的代碼分復(fù)雜，通過debug發(fā)現(xiàn)原來是通過反射調(diào)了SecurityExpressionRoot類的hasRole法：hasRole法的參數(shù)就是我們給url授予的權(quán)限信息：從源碼可以看到，框架認(rèn)為系統(tǒng)所具有的權(quán)限為從登陸信息中的authorities字段，是個GrantedAuthority類型的List。賦予權(quán)限了了，只需要將權(quán)限字符串設(shè)置到其登陸信息的authorities字段即可。鑒權(quán)很簡單，只要戶所具有的和url中授予的任匹配，則表鑒權(quán)通過。不過有點可能你會奇怪，為什么這是調(diào)的hasRole不是ha