數(shù)據(jù)權(quán)限方案設(shè)計(jì)5頁

1、數(shù)據(jù)權(quán)限方案設(shè)計(jì)權(quán)限控制主要分為兩塊，認(rèn)證（Authentication）與授權(quán)（Authorization）。認(rèn)證之后確認(rèn)了身份正確，業(yè)務(wù)系統(tǒng)就會(huì)進(jìn)行授權(quán)，現(xiàn)在業(yè)界比較流行的模型就是RBAC（Role-Based Access Control）。RBAC包含為下面四個(gè)要素：用戶、角色、權(quán)限、資源。用戶是源頭，資源是目標(biāo)，用戶綁定至角色，資源與權(quán)限關(guān)聯(lián)，最終將角色與權(quán)限關(guān)聯(lián)，就形成了比較完整靈活的權(quán)限控制模型。資源是最終需要控制的標(biāo)的物，但是我們在一個(gè)業(yè)務(wù)系統(tǒng)中要將哪些元素作為待控制的資源呢？我將系統(tǒng)中待控制的資源分為三類：1. URL訪問資源（接口以及網(wǎng)頁）2. 界面元素資源（增刪改查導(dǎo)入導(dǎo)

2、出的按鈕，重要的業(yè)務(wù)數(shù)據(jù)展示與否等）3. 數(shù)據(jù)資源現(xiàn)在業(yè)內(nèi)普遍的實(shí)現(xiàn)方案實(shí)際上很粗放，就是單純的“菜單控制”，通過菜單顯示與否來達(dá)到控制權(quán)限的目的。平臺(tái)分為To C和To B兩種：1. To C一般不會(huì)有太多的復(fù)雜權(quán)限控制，甚至大部分連菜單控制都不用，全部都可以訪問。2. To B一般都不是開放的，只要做好認(rèn)證關(guān)口，能夠進(jìn)入系統(tǒng)的只有內(nèi)部員工。大部分企業(yè)內(nèi)部的員工互聯(lián)網(wǎng)知識(shí)有限，而且作為內(nèi)部員工不敢對(duì)系統(tǒng)進(jìn)行破壞性的嘗試。所以針對(duì)現(xiàn)在的情況，考慮成本與產(chǎn)出，大部分設(shè)計(jì)者也不愿意在權(quán)限上進(jìn)行太多的研發(fā)力量。菜單和界面元素一般都是由前端編碼配合存儲(chǔ)數(shù)據(jù)實(shí)現(xiàn)，URL訪問資源的控制也有一些框架比如Sp

3、ringSecurity，Shiro。目前還沒有數(shù)據(jù)權(quán)限控制的框架或者方法，所以自己整理了一份。1、數(shù)據(jù)權(quán)限控制原理數(shù)據(jù)權(quán)限控制最終的效果是會(huì)要求在同一個(gè)數(shù)據(jù)請求方法中，根據(jù)不同的權(quán)限返回不同的數(shù)據(jù)集，而且無需并且不能由研發(fā)編碼控制。這樣大家的第一想法應(yīng)該就是AOP，攔截所有的底層方法，加入過濾條件。這樣的方式兼容性較強(qiáng)，但是復(fù)雜程度也會(huì)更高。我們這套系統(tǒng)中，采用的是利用Mybatis的plugin機(jī)制，在底層SQL解析時(shí)替換增加過濾條件。這樣一套控制機(jī)制存在很明顯的優(yōu)缺點(diǎn)，首先缺點(diǎn)：1. 適用性有限，基于底層的Mybatis。2. 方言有限，針對(duì)了某種數(shù)據(jù)庫（我們使用Mysql），而且由于需

4、要在底層解析處理?xiàng)l件所以有可能造成不同的數(shù)據(jù)庫不能兼容。當(dāng)然Redis和NoSQL也無法限制。當(dāng)然，假如你現(xiàn)在就用Mybatis，而且數(shù)據(jù)庫使用的是Mysql，這方面就沒有太大影響了。接下來說說優(yōu)點(diǎn)：1. 減少了接口數(shù)量及接口復(fù)雜度。原本針對(duì)不同的角色，可能會(huì)區(qū)分不同的接口或者在接口實(shí)現(xiàn)時(shí)利用流程控制邏輯來區(qū)分不同的條件。有了數(shù)據(jù)權(quán)限控制，代碼中只用寫基本邏輯，權(quán)限過濾由底層機(jī)制自動(dòng)處理。2. 提高了數(shù)據(jù)權(quán)限控制的靈活性。例如原本只有主管能查本部門下組織架構(gòu)/訂單數(shù)據(jù)，現(xiàn)在新增助理角色，能夠查詢本部門下組織架構(gòu)，不能查詢訂單。這樣的話普通的寫法就需要調(diào)整邏輯控制，使用數(shù)據(jù)權(quán)限控制的話，直接修改

5、配置就好。2、數(shù)據(jù)權(quán)限實(shí)現(xiàn)上一節(jié)就提及了實(shí)現(xiàn)原理，是基于Mybatis的plugins（查看官方文檔）實(shí)現(xiàn)。MyBatis 允許你在已映射語句執(zhí)行過程中的某一點(diǎn)進(jìn)行攔截調(diào)用。默認(rèn)情況下，MyBatis 允許使用插件來攔截的方法調(diào)用包括：Executor (update, query, flushStatements, commit, rollback, getTransaction, close, isClosed)ParameterHandler (getParameterObject, setParameters)ResultSetHandler (handleResultSets, ha

6、ndleOutputParameters)StatementHandler (prepare, parameterize, batch, update, query)Mybatis的插件機(jī)制目前比較出名的實(shí)現(xiàn)應(yīng)該就是PageHelper項(xiàng)目了，在做這個(gè)實(shí)現(xiàn)的時(shí)候也參考了PageHelper項(xiàng)目的實(shí)現(xiàn)方式。所以權(quán)限控制插件的類命名為PermissionHelper。機(jī)制是依托于Mybatis的plugins機(jī)制，實(shí)際SQL處理的時(shí)候基于jsqlparser這個(gè)包。設(shè)計(jì)中包含兩個(gè)類，一個(gè)是保存角色與權(quán)限的實(shí)體類命名為PermissionRule，一個(gè)是根據(jù)實(shí)體變更底層SQL語句的主體方法類Perm

7、issionHelper。數(shù)據(jù)結(jié)構(gòu)中保存如下幾個(gè)字段：· 角色列表：需要使用此規(guī)則的角色，可以多個(gè)，使用英文逗號(hào)隔開。· 實(shí)體列表：對(duì)應(yīng)的規(guī)則應(yīng)用的實(shí)體（這里指的是表結(jié)構(gòu)中的表名，可能你的實(shí)體是駝峰而數(shù)據(jù)庫是蛇形，所以這里要放蛇形那個(gè)），可以多個(gè)，使用英文逗號(hào)隔開。· 表達(dá)式：表達(dá)式就是數(shù)據(jù)權(quán)限控制的核心了。簡單的說這里的表達(dá)式就是一段SQL語句，其中設(shè)置了一些可替換值，底層會(huì)用對(duì)應(yīng)運(yùn)行時(shí)的變量替換對(duì)應(yīng)內(nèi)容，從而達(dá)到增加條件的效果。· 規(guī)則說明：單純的一個(gè)說明字段。核心流程系統(tǒng)啟動(dòng)時(shí)，首先從數(shù)據(jù)庫加載出所有的規(guī)則。底層利用插件機(jī)制來攔截所有的查詢語句，進(jìn)

8、入查詢攔截方法后，首先根據(jù)當(dāng)前用戶的權(quán)限列表篩選出PermissionRule列表，然后循環(huán)列表中的規(guī)則，對(duì)語句中符合實(shí)體列表的表進(jìn)行條件增加，最終生成處理后的SQL語句，退出攔截器，Mybatis執(zhí)行處理后SQL并返回結(jié)果。頭部只是標(biāo)準(zhǔn)的Mybatis攔截器寫法，注解中的Signature決定了你的代碼對(duì)哪些方法攔截，update實(shí)際上針對(duì)修改（Update）、刪除（Delete）生效，query是對(duì)查詢（Select）生效。重點(diǎn)思路重點(diǎn)其實(shí)就在于Sql的解析和條件注入，使用開源項(xiàng)目JSqlParser。· 解析出MainTable和JoinTable。from之后跟著的稱為Mai

9、nTable，join之后跟著的稱為JoinTable。這兩個(gè)就是我們PermissionRule需要匹配的表名，PermissionRule:fromEntity字段。· 解析出MainTable的where和JoinTable的on后面的條件。使用and連接原本的條件和待注入的條件，PermissionRule:exps字段。· 使用當(dāng)前登錄的用戶信息（放在緩存中），替換條件表達(dá)式中的值。· 某些情況需要忽略權(quán)限，可以考慮使用ThreadLocal（單機(jī)）/Redis（集群）來控制3、使用1、數(shù)據(jù)準(zhǔn)別：a、創(chuàng)建數(shù)據(jù)庫，儲(chǔ)存權(quán)限規(guī)則，表為permission_r

10、uleb、用戶登錄時(shí)，到數(shù)據(jù)庫查詢用戶擁有角色所擁有的permission_rule，將其設(shè)置返回前端儲(chǔ)存c、前端每次發(fā)送請求時(shí)，攜帶pemission_rule的信息2、定義數(shù)據(jù)權(quán)限插件a、仿照PageHelper的工作原理，創(chuàng)建PermissionHelper，定義權(quán)限開關(guān)方法startData (),開始權(quán)限攔截b、攔截器攔截sql，判斷是否開始攔截，開始攔截，按照rule規(guī)則，攔截并拼接sql3、定義PermissionHelper的使用開關(guān)因startData()是靜態(tài)方法，只能操作靜態(tài)成員變量，在并發(fā)時(shí)會(huì)有安全問題，步驟如下：a、使用ThreadLocal作為全局變量，存儲(chǔ)當(dāng)前線程

11、的變量b、引入json，將Permission_rule格式化成字符串，再在PermissionHelper中解析成LIstc、在需要數(shù)據(jù)權(quán)限的地方使用PermissionHelper.startData(header),參數(shù)為前端傳回的登錄用戶信息d、因PermissionHelper在utils工程，方便其他工程引用，所以在header不能直接傳，采用json字符串來傳e、PermissionHelper實(shí)現(xiàn)了Mybatis的 Interceptor接口，并且攔截perpare方法，才能對(duì)sql進(jìn)行操作并返回給mybatis去執(zhí)行（攔截query方法無效）f、PermissionHelpe

12、r對(duì)是否需要數(shù)據(jù)權(quán)限進(jìn)行判斷，此變量放在了TreadLocal中，有且僅有當(dāng)前線程能訪問g、對(duì)header的json字符串進(jìn)行解析，有權(quán)限規(guī)則Listh、對(duì)權(quán)限規(guī)則list進(jìn)行遍歷，按主表、從表的順序進(jìn)行匹配規(guī)則、替換變量i、返回sql，給mybatis執(zhí)行h、執(zhí)行完需關(guān)閉權(quán)限控制開關(guān)4、用法1、引maven坐標(biāo)<dependency> <groupId>com.auth</groupId> <artifactId>ac-framework-utils</artifactId> <version>1.0-SNAPSHOT&

13、lt;/version></dependency>2、編寫權(quán)限規(guī)則在permission_rule表中編寫權(quán)限規(guī)則，各字段解釋如下：Name： 規(guī)則名稱Ids ：適用角色id列表，格式如：1,2，(用逗號(hào)隔開)Main_tables ：適用的主表，格式如: Role,User, (用逗號(hào)隔開)Exps ：過濾表達(dá)式字段，uid 會(huì)自動(dòng)替換為當(dāng)前用戶的userId，me 主實(shí)體名稱me.a 主實(shí)體別名格式如：userId = uid(userId = uid AND authType > 3)(userId = uid AND authType) > 3 OR (dept in (select dept from depts where manager.id = uid)4、將controller中的request解析出用戶信息，如下所示/當(dāng)前登錄用戶信息AcOauth2Util acOauth2Util=new AcOauth2Util();AcOauth2Util.UserJwt userJwtFromHeader = acOauth2Util.getUserJ