權限系統(tǒng)設計
前言
權限管理是所有后臺系統(tǒng)的都會涉及的一個重要組成部分，主要目的是對不同的人訪問資源進行權限的控制，避免因權限控制缺失或操作不當引發(fā)的風險問題，如操作錯誤，隱私數(shù)據(jù)泄露等問題。
目前在公司負責權限這塊,所以對權限這塊的設計比較熟悉,公司采用微服務架構,權限系統(tǒng)自然就獨立出來了,其他業(yè)務系統(tǒng)包括商品中心,訂單中心,用戶中心,倉庫系統(tǒng),小程序,多個APP等十幾個系統(tǒng)和終端
1.權限模型
迄今為止最為普及的權限設計模型是RBAC模型,基于角色的訪問控制（Role-Based Access Control)
1.1 RBAC0模型
RBAC0模型如下:
這是權限最基礎也是最核心的模型,它包括用戶/角色/權限,其中用戶和角色是多對多的關系,角色和權限也是多對多的關系。
用戶是發(fā)起操作的主體,按類型分可分為2B和2C用戶,可以是后臺管理系統(tǒng)的用戶,可以是OA系統(tǒng)的內(nèi)部員工,也可以是面向C端的用戶,比如阿里云的用戶。
角色起到了橋梁的作用,連接了用戶和權限的關系,每個角色可以關聯(lián)多個權限,同時一個用戶關聯(lián)多個角色,那么這個用戶就有了多個角色的多個權限。有人會問了為什么用戶不直接關聯(lián)權限呢?在用戶基數(shù)小的系統(tǒng),比如20個人的小系統(tǒng),管理員可以直接把用戶和權限關聯(lián),工作量并不大,選擇一個用戶勾選下需要的權限就完事了。
但是在實際企業(yè)系統(tǒng)中,用戶基數(shù)比較大,其中很多人的權限都是一樣的,就是個普通訪問權限,如果管理員給100人甚至更多授權,工作量巨大。這就引入了"角色(Role)"概念,一個角色可以與多個用戶關聯(lián),管理員只需要把該角色賦予用戶,那么用戶就有了該角色下的所有權限,這樣設計既提升了效率,也有很大的拓展性。
權限是用戶可以訪問的資源,包括頁面權限,操作權限,數(shù)據(jù)權限:
頁面權限:
即用戶登錄系統(tǒng)可以看到的頁面,由菜單來控制,菜單包括一級菜單和二級菜單,只要用戶有一級和二級菜單的權限,那么用戶就可以訪問頁面
操作權限:
即頁面的功能按鈕,包括查看,新增,修改,刪除,審核等,用戶點擊刪除按鈕時,后臺會校驗用戶角色下的所有權限是否包含該刪除權限,如果是,就可以進行下一步操作,反之提示無權限。
有的系統(tǒng)要求"可見即可操作",意思是如果頁面上能夠看到操作按鈕,那么用戶就可以操作,要實現(xiàn)此需求,這里就需要前端來配合,前端開發(fā)把用戶的權限信息緩存,在頁面判斷用戶是否包含此權限,如果有,就顯示該按鈕,如果沒有,就隱藏該按鈕。某種程度上提升了用戶體驗,但是在實際場景可自行選擇是否需要這樣做
數(shù)據(jù)權限:
數(shù)據(jù)權限就是用戶在同一頁面看到的數(shù)據(jù)是不同的,比如財務部只能看到其部門下的用戶數(shù)據(jù),采購部只看采購部的數(shù)據(jù),在一些大型的公司,全國有很多城市和分公司,比如杭州用戶登錄系統(tǒng)只能看到杭州的數(shù)據(jù),上海用戶只能看到上海的數(shù)據(jù),解決方案一般是把數(shù)據(jù)和具體的組織架構關聯(lián)起來.
舉個例子,再給用戶授權的時候,用戶選擇某個角色同時綁定組織如財務部或者合肥分公司,那么該用戶就有了該角色下財務部或合肥分公司下的的數(shù)據(jù)權限。
以上是RBAC的核心設計及模型分析,此模型也叫做RBAC0,而基于核心概念之上,RBAC還提供了擴展模式。包括RBAC1,RBAC2,RBAC3模型。下面介紹這三種類型
1.2 RBAC1模型
此模型引入了角色繼承(Hierarchical Role)概念,即角色具有上下級的關系,角色間的繼承關系可分為一般繼承關系和受限繼承關系。
一般繼承關系僅要求角色繼承關系是一個絕對偏序關系，允許角色間的多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構，實現(xiàn)角色間的單繼承。這種設計可以給角色分組和分層，一定程度簡化了權限管理工作。
1.3 RBAC2模型
基于核心模型的基礎上，進行了角色的約束控制,RBAC2模型中添加了責任分離關系,其規(guī)定了權限被賦予角色時，或角色被賦予用戶時，以及當用戶在某一時刻激活一個角色時所應遵循的強制性規(guī)則。責任分離包括靜態(tài)責任分離和動態(tài)責任分離。
主要包括以下約束:
互斥角色:同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則?；コ饨巧侵父髯詸嘞藁ハ嘀萍s的兩個角色。比如財務部有會計和審核員兩個角色,他們是互斥角色,那么用戶不能同時擁有這兩個角色,體現(xiàn)了職責分離原則
基數(shù)約束:一個角色被分配的用戶數(shù)量受限；一個用戶可擁有的角色數(shù)目受限；同樣一個角色對應的訪問權限數(shù)目也應受限，以控制高級權限在系統(tǒng)中的分配
先決條件角色:即用戶想獲得某上級角色,必須先獲得其下一級的角色
1.4 RBAC3模型
即最全面的權限管理,它是基于RBAC0,將RBAC1和RBAC2進行了整合
1.5 用戶組
當平臺用戶基數(shù)增大，角色類型增多時，而且有一部分人具有相同的屬性,比如財務部的所有員工,如果直接給用戶分配角色，管理員的工作量就會很大,如果把相同屬性的用戶歸類到某用戶組,那么管理員直接給用戶組分配角色,用戶組里的每個用戶即可擁有該角色,以后其他用戶加入用戶組后,即可自動獲取用戶組的所有角色,退出用戶組,同時也撤銷了用戶組下的角色,無須管理員手動管理角色。
根據(jù)用戶組是否有上下級關系,可以分為有上下級的用戶組和普通用戶組:
具有上下級關系的用戶組:最典型的例子就是部門和職位,可能多數(shù)人沒有把部門職位和用戶組關聯(lián)起來吧。當然用戶組是可以拓展的,部門和職位常用于內(nèi)部的管理系統(tǒng),如果是面向C端的系統(tǒng),比如淘寶網(wǎng)的商家,商家自身也有一套組織架構,比如采購部,銷售部,客服部,后勤部等,有些人擁有客服權限,有些人擁有上架權限等等,所以用戶組是可以拓展的
普通用戶組:即沒有上下級關系,和組織架構,職位都沒有關系,也就是說可以跨部門,跨職位,舉個例子,某電商后臺管理系統(tǒng),有拼團活動管理角色,我們可以設置一個拼團用戶組,該組可以包括研發(fā)部的后臺開發(fā)人員,運營部的運營人員,采購部的人員等等。
每個公司都會涉及到到組織和職位,下面就重點介紹這兩個。
1.5.1 組織
常見的組織架構如下圖:
我們可以把組織與角色進行關聯(lián),用戶加入組織后,就會自動獲得該組織的全部角色,無須管理員手動授予,大大減少工作量,同時用戶在調(diào)崗時,只需調(diào)整組織,角色即可批量調(diào)整。組織的另外一個作用是控制數(shù)據(jù)權限,把角色關聯(lián)到組織,那么該角色只能看到該組織下的數(shù)據(jù)權限。
1.5.2 職位
假設財務部的職位如下圖:
每個組織部門下都會有多個職位,比如財務部有總監(jiān),會計,出納等職位,雖然都在同一部門,但是每個職位的權限是不同的,職位高的擁有更多的權限。總監(jiān)擁有所有權限,會計和出納擁有部分權限。特殊情況下,一個人可能身兼多職。
1.6 含有組織/職位/用戶組的模型
根據(jù)以上場景,新的權限模型就可以設計出來了,如下圖:
根據(jù)系統(tǒng)的復雜度不同,其中的多對多關系和一對一關系可能會有變化
在單系統(tǒng)且用戶類型單一的情況下,用戶和組織是一對一關系,組織和職位是一對多關系,用戶和職位是一對一關系,組織和角色是一對一關系,職位和角色是一對一關系,用戶和用戶組是多對對關系,用戶組和角色是一對一關系,當然這些關系也可以根據(jù)具體業(yè)務進行調(diào)整。模型設計并不是死的,如果小系統(tǒng)不需要用戶組,這塊是可以去掉的。
分布式系統(tǒng)且用戶類型單一的情況下,到這里權限系統(tǒng)就會變得很復雜,這里就要引入了一個"系統(tǒng)"概念,此時系統(tǒng)架構是個分布式系統(tǒng),權限系統(tǒng)獨立出來,負責所有的系統(tǒng)的權限控制,其他業(yè)務系統(tǒng)比如商品中心,訂單中心,用戶中心,每個系統(tǒng)都有自己的角色和權限,那么權限系統(tǒng)就可以配置其他系統(tǒng)的角色和權限。
分布式系統(tǒng)且用戶類型多個的情況下,比如淘寶網(wǎng),它的用戶類型包括內(nèi)部用戶,商家,普通用戶,內(nèi)部用戶登錄多個后臺管理系統(tǒng),商家登錄商家中心,這些做權限控制,如果你作為架構師,該如何來設計呢?大神可以在評論區(qū)留言交流哦!
2.授權流程
授權即給用戶授予角色,按流程可分為手動授權和審批授權。權限中心可同時配置這兩種,可提高授權的靈活性。
手動授權:管理員登錄權限中心為用戶授權,根據(jù)在哪個頁面授權分為兩種方式:給用戶添加角色,給角色添加用戶。
給用戶添加角色就是在用戶管理頁面,點擊某個用戶去授予角色,可以一次為用戶添加多個角色;給角色添加用戶就是在角色管理頁面,點擊某個角色,選擇多個用戶,實現(xiàn)了給批量用戶授予角色的目的。
審批授權:即用戶申請某個職位角色,那么用戶通過OA流程申請該角色,然后由上級審批,該用戶即可擁有該角色,不需要系統(tǒng)管理員手動授予。
3.表結構
有了上述的權限模型,設計表結構就不難了,下面是多系統(tǒng)下的表結構,簡單設計下,主要提供思路:
4.權限框架
- Apache Shrio
- Spring Security
在項目中可以采用其中一種框架,它們的優(yōu)缺點以及如何使用會在后面的文章中詳細介紹.
5.結語
權限系統(tǒng)可以說是整個系統(tǒng)中最基礎,同時也可以很復雜的,在實際項目中,會遇到多個系統(tǒng),多個用戶類型,多個使用場景,這就需要具體問題具體分析,但最核心的RBAC模型是不變的,我們可以在其基礎上進行擴展來滿足需求。
最后,如果您覺得這篇文章對您有幫助,可以點個再看,謝謝支持!
【責任編輯：張燕妮 TEL：（010）68476606】