1權(quán)限模型
1.1 權(quán)限設(shè)計
從業(yè)務(wù)分類上來講權(quán)限可以分為數(shù)據(jù)查看權(quán)限乞而，數(shù)據(jù)修改權(quán)限等哈踱，對應(yīng)到系統(tǒng)設(shè)計中有頁面權(quán)限荒适、菜單權(quán)限、按鈕權(quán)限等开镣。菜單也分一級菜單刀诬、二級菜單甚至三級菜單，以csdn文章編輯頁面左側(cè)菜單欄為例是分了兩級菜單邪财。菜單對應(yīng)的頁面里又有很多按鈕陕壹，我們在設(shè)計的時候最好把權(quán)限設(shè)計成樹形結(jié)構(gòu)，這樣在申請權(quán)限的時候就可以一目了然的看到菜單的結(jié)構(gòu)卧蜓，需要哪些權(quán)限就非常的明了了帐要。
如下圖所示：
按照這個架構(gòu)，按鈕的父級是二級菜單弥奸，二級菜單的父級是一級菜單榨惠，這樣用戶申請權(quán)限的時候非常清晰的看到自己需要哪些權(quán)限。
1.2 為什么需要角色
權(quán)限結(jié)構(gòu)梳理清晰之后盛霎，需要思考怎么把權(quán)限分配給用戶赠橙，用戶少的情況下，可以直接分配愤炸，一個用戶可以有多個權(quán)限期揪，統(tǒng)一一個權(quán)限可以被多個用戶擁有，用戶-權(quán)限的模型結(jié)構(gòu)如下所示：
這種模型能夠滿足權(quán)限的基本分配能力规个，但是隨著用戶數(shù)量的增長凤薛，這種模型的弊端就凸顯出來了，每一個用戶都需要去分配權(quán)限诞仓，非常的浪費管理員的時間和精力缤苫，并且用戶和權(quán)限雜亂的對應(yīng)關(guān)系會給后期帶來巨大的維護成本。用戶-權(quán)限對應(yīng)關(guān)系圖：
這種對應(yīng)關(guān)系在用戶多的情況下基本無法維護了墅拭。其實很多用戶負責同一個業(yè)務(wù)模塊所需要的權(quán)限是一樣的活玲，這樣的話我們是不是可以借助第三個媒介，把需要相同的權(quán)限都分配給這個媒介谍婉，然后用戶和媒介關(guān)聯(lián)起來舒憾，用戶就擁有了媒介的權(quán)限了。這就是經(jīng)典的RBAC模型穗熬，其中媒介就是我們通常所說的角色镀迂。
1.3 權(quán)限模型的演進
1.3.1 RBAC模型
有了角色之后可以把權(quán)限分配給角色，需要相同權(quán)限的用戶和角色對應(yīng)起來就可以了唤蔗，一個權(quán)限可以分配給多個角色招拙，一個角色可以擁有多個權(quán)限唧瘾，同樣一個用戶可以分配多個角色，一個角色也可以對應(yīng)多個用戶别凤，對應(yīng)模型如下所示：
這就是經(jīng)典的RBAC模型了（role-based-access-control），在這里面角色起到了橋梁左右领虹，連接了用戶和權(quán)限的關(guān)系规哪，每個角色可以擁有多個權(quán)限，每個用戶可以分配多個角色塌衰，這樣用戶就擁有了多個角色的多個權(quán)限诉稍。
同時因為有角色作為媒介，大大降低了錯綜復(fù)雜的交互關(guān)系最疆，比如一家有上萬人的公司杯巨，角色可能只需要幾百個就搞定了，因為很多用戶需要的權(quán)限是一樣的努酸，分配一樣的角色就可以了服爷。這種模型的對應(yīng)關(guān)系圖如下所示：
用戶和角色，角色和權(quán)限都是多對多的關(guān)系获诈，這種模型是最通用的權(quán)限管理模型仍源，節(jié)省了很大的權(quán)限維護成本， 但是實際的業(yè)務(wù)千變?nèi)f化舔涎，權(quán)限管理的模型也需要根據(jù)不同的業(yè)務(wù)模型適當?shù)恼{(diào)整笼踩，比如一個公司內(nèi)部的組織架構(gòu)是分層級的，層級越高權(quán)限越大亡嫌，因為層級高的人不僅要擁有自己下屬擁有的權(quán)限嚎于，二期還要有一些額外的權(quán)限。
RBAC模型可以給不同層級的人分配不同的角色挟冠，層級高的對應(yīng)角色的權(quán)限就多于购，這樣的處理方式可以解決問題，但是有沒有更好的解決辦法呢圃郊，答案肯定是有的价涝，這就引出角色繼承的RBAC模型。
1.3.2 角色繼承的RBAC模型
角色繼承的RBAC模型又稱RBAC1模型持舆。每個公司都有自己的組織架構(gòu)色瘩，比如公司里管理財務(wù)的人員有財務(wù)總監(jiān)、財務(wù)主管逸寓、出納員等居兆，財務(wù)主管需要擁有但不限于出納員的權(quán)限，財務(wù)總監(jiān)需要擁有但不限于財務(wù)主管的權(quán)限竹伸，像這種管理關(guān)系向下兼容的模式就需要用到角色繼承的RBAC模型泥栖。角色繼承的RBAC模型的思路是上層角色繼承下層角色的所有權(quán)限簇宽，并且可以額外擁有其他權(quán)限。
模型如下所示：
[圖片上傳失敗...(image-24e233-1660522526490)]
從模型圖中可以看出下級角色擁有的權(quán)限吧享，上級角色都擁有魏割，并且上級角色可以擁有其他的權(quán)限。角色的層級關(guān)系可以分為兩種钢颂，一種是下級角色只能擁有一個上級角色钞它，但是上級角色可以擁有多個下級角色，這種結(jié)構(gòu)用圖形表示是一個樹形結(jié)構(gòu)殊鞭，如下圖所示：
還有一種關(guān)系是下級角色可以擁有多個上級角色遭垛，上級角色也可以擁有多個下級角色，這種結(jié)構(gòu)用圖形表示是一個有向無環(huán)圖操灿，如下圖所示：
樹形圖是我們比較常用的锯仪，因為一個用戶一般情況下不會同時有多個直屬上級，比如財務(wù)部只能有一個財務(wù)總監(jiān)趾盐，但是可以有多個財務(wù)主管和收納員庶喜。
1.3.3 帶約束的RBAC模型
帶約束的RBAC模型又成RBAC2模型。在實際工作中谤碳，為了安全的考慮會有很多約束條件溃卡，比如財務(wù)部里同一個人不能即是會計又是審核員，跟一個人同一時間不能即是運動員又是裁判員是一個道理的蜒简，又比如財務(wù)部的審核員不能超過2個瘸羡，不能1個也沒有。因為角色和權(quán)限是關(guān)聯(lián)的搓茬，所以我們做好角色的約束就可以了犹赖。
常見的約束條件有：角色互斥、基數(shù)約束卷仑、先決條件約束等峻村。
角色互斥： 如果角色A和角色B是互斥關(guān)系的話，那么一個用戶同一時間不能即擁有角色A锡凝，又擁有角色B粘昨，只能擁有其中的一個角色。
比如我們給一個用戶賦予了會計的角色就不能同時再賦予審核員的角色窜锯，如果想擁有審核員的角色就必須先去掉會計的角色张肾。假設(shè)提交角色和審核角色是互質(zhì)的，我們可以用圖形表示：
基數(shù)約束： 同一個角色被分配的用戶數(shù)量可以被限制锚扎，比如規(guī)定擁有超級管理員角色的用戶有且只有1個吞瞪；用戶被分配的角色數(shù)量也需要被限制，角色被分配的權(quán)限數(shù)量也可以被限制驾孔。
先決條件約束：用戶想被賦予上級角色芍秆，首先需要擁有下級角色惯疙，比如技術(shù)負責人的角色和普通技術(shù)員工角色是上下級關(guān)系，那么用戶想要用戶技術(shù)負責人的角色就要先擁有普通技術(shù)員工的角色妖啥。
1.4 用戶劃分
1.4.1 用戶組
我們創(chuàng)建角色是為了解決用戶數(shù)量大的情況下霉颠，用戶分配權(quán)限繁瑣以及用戶-權(quán)限關(guān)系維護成本高的問題。抽象出一個角色荆虱，把需要一起操作的權(quán)限分配給這個角色掉分，把角色賦予用戶，用戶就擁有了角色上的權(quán)限克伊，這樣避免了一個個的給用戶分配權(quán)限，節(jié)省了大量的資源华坦。
同樣的如果有一批用戶需要相同的角色愿吹，我們也需要一個個的給用戶分配角色，比如一個公司的客服部門有500多個人惜姐，有一天研發(fā)部研發(fā)了一套查詢后臺數(shù)據(jù)的產(chǎn)品犁跪，客服的小伙伴都需要使用，但是客服由于之前并沒有統(tǒng)一的一個角色給到所有的客服小伙伴歹袁，這時候需要新加一個角色坷衍，把權(quán)限分配給該角色，然后再把角色一個個分配給客服人員条舔，這時候會發(fā)現(xiàn)給500個用戶一個個添加角色非常的麻煩枫耳。但是客服人員又有共同的屬性，所以我們可以創(chuàng)建一個用戶組孟抗，所有的客服人員都屬于客服用戶組迁杨，把角色分配給客服用戶組，這個用戶組下面的所有用戶就擁有了需要的權(quán)限凄硼。
RBAC模型添加用戶組之后的模型圖如下所示：
很多朋友會問铅协，用戶組和角色有什么區(qū)別呢？簡單的來說摊沉，用戶組是一群用戶的組合狐史，而角色是用戶和權(quán)限之間的橋梁。 用戶組把相同屬性的用戶組合起來说墨，比如同一個項目的開發(fā)骏全、產(chǎn)品、測試可以是一個用戶組婉刀，同一個部門的相同職位的員工可以是一個用戶組吟温， 一個用戶組可以是一個職級，可以是一個部門突颊，可以是一起做事情的來自不同崗位的人鲁豪。
用戶可以分組潘悼，權(quán)限也可以分組，權(quán)限特別多的情況下爬橡，可以把一個模塊的權(quán)限組合起來成為一個權(quán)限組治唤，權(quán)限組也是解決權(quán)限和角色對應(yīng)關(guān)系復(fù)雜的問題。
比如我們定義權(quán)限的時候一級菜單糙申、二級菜單宾添、按鈕都可以是權(quán)限，一個一級菜單下面有幾十個二級菜單柜裸，每個二級菜單下面又有幾十個按鈕缕陕，這時候我們把權(quán)限一個個分配給角色也是非常麻煩的，可以采用分組的方法把權(quán)限分組疙挺，然后把分好的組賦予角色就可以了扛邑。
給權(quán)限分組也是個技術(shù)活，需要理清楚權(quán)限之間的關(guān)系铐然，比如支付的運營后臺我們需要查各種信息蔬崩，賬務(wù)的數(shù)據(jù)、訂單的數(shù)據(jù)搀暑、商戶的數(shù)據(jù)等等沥阳，這些查詢的數(shù)據(jù)并不在一個頁面，每個頁面也有很多按鈕自点，我們可以把這幾個頁面以及按鈕對應(yīng)的權(quán)限組合成一個權(quán)限組賦予角色桐罕。加入權(quán)限組之后的RBAC模型如下所示：
實際工作中我們很少給權(quán)限分組，給用戶分組的場景會多一些樟氢，有的時候用戶組也可以直接和權(quán)限關(guān)聯(lián)冈绊，這個看實際的業(yè)務(wù)場景是否需要，權(quán)限模型沒有統(tǒng)一的埠啃，業(yè)務(wù)越復(fù)雜業(yè)務(wù)模型會約多樣化死宣。
1.4.2 組織
每個公司都有自己的組織架構(gòu)，很多時候權(quán)限的分配可以根據(jù)組織架構(gòu)來劃分碴开。因為同一個組織內(nèi)的小伙伴使用的大部分權(quán)限是一樣的毅该。如下所示一個公司的組織架構(gòu)圖：
[圖片上傳失敗...(image-22a03a-1660522526488)]
按照這個組織架構(gòu)，每一個組織里的成員使用的基礎(chǔ)權(quán)限很可能是一樣的潦牛，比如人力資源都需要看到人才招聘的相關(guān)信息眶掌，市場推廣都需要看到行業(yè)分析的相關(guān)信息，按照組織來分配角色會有很多優(yōu)勢：
實現(xiàn)權(quán)限分配的自動化： 和組織關(guān)系打通之后巴碗，按照組織來分配角色朴爬，如果有新入職的用戶，被劃分在某個組織下面之后橡淆，會自動獲取該組織下所有的權(quán)限召噩，無需人工分配母赵。又比如有用戶調(diào)崗，只需要把組織關(guān)系調(diào)整就可以了具滴，權(quán)限會跟著組織關(guān)系自動調(diào)整凹嘲，也無需人工干預(yù)。這么做首先需要把權(quán)限和組織關(guān)系打通构韵。
控制數(shù)據(jù)權(quán)限： 把角色關(guān)聯(lián)到組織周蹭，組織里的成員只能看到本組織下的數(shù)據(jù)，比如市場推廣和大客定制疲恢，市場推廣針對的是零散的客戶凶朗，大可定制針對的是有一定體量的客戶，相互的數(shù)據(jù)雖然在一個平臺显拳，但是只能看自己組織下的數(shù)據(jù)俱尼。
加入組織之后的RBAC模型如下所示：
用戶可以在多個組織中，因為組織也有層級結(jié)構(gòu)萎攒，一個組織里只可以有多個用戶，所以用戶和組織的關(guān)系是多對多的關(guān)系矛绘，組織和角色的關(guān)系是一對一的關(guān)系耍休。這個在工作中可以根據(jù)實際情況來確定對應(yīng)關(guān)系升略。
1.4.3 職位
一個組織下面會有很多職位徐许，比如財務(wù)管理會有財務(wù)總監(jiān)、財務(wù)主管絮短、會計囚玫、出納員等職位喧锦，每個職位需要的權(quán)限是不一樣的，可以像組織那樣根據(jù)職位來分配不同的角色抓督，由于一個人的職位是固定的燃少，所以用戶跟職位的對應(yīng)關(guān)系時一對一的關(guān)系，職位跟角色的對應(yīng)關(guān)系可以是多對多的關(guān)系铃在。加入職位的RBAC模型如下所示：
1.5 理想的RBAC模型
RBAC模型根據(jù)不同業(yè)務(wù)場景的需要會有很多種演變阵具，實際工作中業(yè)務(wù)是非常復(fù)雜的，權(quán)限分配也是非常復(fù)雜的定铜，想要做出通用且高效的模型很困難阳液。我們把RBAC模型的演變匯總起來會是一個支撐大數(shù)據(jù)量以及復(fù)雜業(yè)務(wù)的理想的模型。把RBAC揣炕、RBAC1帘皿、RBAC2、用戶組畸陡、組織鹰溜、職位匯總起來的模型如下所示：
按照這個模型基本上能夠解決所有的權(quán)限問題虽填，其中的對應(yīng)關(guān)系可以根據(jù)實際的業(yè)務(wù)情況來確定，一般情況下奉狈，組織和職位是一對多的關(guān)系卤唉，特殊情況下可以有多對多的情況，需要根據(jù)實際情況來定仁期。
理想的RBAC模型并不是說我們一開始建權(quán)限模型就可以這么做桑驱，而是數(shù)據(jù)體量、業(yè)務(wù)復(fù)雜度達到一定程度之后可以使用這個模型來解決權(quán)限的問題跛蛋，如果數(shù)據(jù)量特別少熬的，比如剛成立的公司只有十幾個人，那完全可以用用戶-權(quán)限模型赊级，都沒有必要使用RBAC模型押框。
2 權(quán)限系統(tǒng)表設(shè)計
2.1 標準RBAC模型表設(shè)計
標準RBAC模型的表是比較簡單了，要表示用戶-角色-權(quán)限三者之前的關(guān)系理逊，首先要創(chuàng)建用戶表橡伞、角色表、權(quán)限表晋被，用戶和角色是多對多的關(guān)系兑徘，角色和權(quán)限是多對多的關(guān)系，需要再創(chuàng)建兩章關(guān)系表羡洛，分別是用戶-角色關(guān)系表和角色-權(quán)限關(guān)系表挂脑。這六張表的ER圖如下所示：
3.2 理想RBAC模型表設(shè)計
理想的RBAC模型是標準RBAC模型經(jīng)過多次擴展得到的，表結(jié)構(gòu)也會比較復(fù)雜欲侮，因為要維護很多關(guān)系崭闲，如下圖所示是理想的RBAC模型的ER圖：
這里面需要強調(diào)的是角色互斥表，互斥的關(guān)系可以放在角色上威蕉，也可以放在權(quán)限上刁俭，看實際工作的需求。
