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

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

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

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

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

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

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

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

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

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

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

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

12、風(fēng)格的表達(dá)式。這三種設(shè)置分別是：1、固定請(qǐng)求法，但匹配所有url的AuthorizedUrl2、固定請(qǐng)求法，固定url的AuthorizedUrl3、只固定url的AuthorizedUrl且1其實(shí)就是使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通過源碼可以看出，其實(shí)返回的就是個(gè)SPEL表達(dá)式，role和authority的不同之處在于如果使hasRole則表使的是url，注冊(cè)時(shí)不能帶ROLE_前綴，框架會(huì)給你動(dòng)補(bǔ)上這個(gè)前綴。使authority表使的是url權(quán)限，則沒有任何限制。也就是說通過框架提供的這種特性我們可以對(duì)于同個(gè)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ì)。之前的章中已經(jīng)介紹了SpringSecurity的基本設(shè)計(jì)模式，所以SecurityConfigurer的init法是我們閱讀源碼時(shí)必須了解的。但是通過源碼可以看到ExpressURLAuthorizationConfigurer以及其所有類都沒有重寫init法，根據(jù)init法的初衷，可以知道ExpressURLAuthorizationConfigurer是個(gè)功能相對(duì)較獨(dú)的模塊，因?yàn)樗麤]有經(jīng)過init法設(shè)置共享變量。3、SecurityConfigurer的configure法init法是來設(shè)置共享變

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

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

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

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