權限系統設計
前言
權限管理是所有背景系統的都會涉及的一個重要組成部分，主要目的是對不同的人通路資源進行權限的控制，避免因權限控制缺失或操作不當引發的風險問題，如操作錯誤，隐私資料洩露等問題。
1.權限模型
迄今為止最為普及的權限設計模型是RBAC模型,基于角色的通路控制（Role-Based Access Control)
1.1 RBAC-0模型
RBAC-0模型
RBAC-0模型是權限最基礎也是最核心的模型,它包括使用者/角色/權限,其中使用者和角色是多對多的關系,角色和權限也是多對多的關系。
使用者 是發起操作的主體,按類型分可分為2B和2C使用者,可以是背景管理系統的使用者,可以是OA系統的内部員工,也可以是面向C端的使用者,比如阿裡雲的使用者。
角色 起到了橋梁的作用,連接配接了使用者和權限的關系,每個角色可以關聯多個權限,同時一個使用者關聯多個角色,那麼這個使用者就有了多個角色的多個權限。
有人會問了為什麼使用者不直接關聯權限呢？在使用者基數小的系統,比如20個人的小系統，管理者可以直接把使用者和權限關聯，工作量并不大，選擇一個使用者勾選下需要的權限就完事了。
但是在實際企業系統中，使用者基數比較大,其中很多人的權限都是一樣的，就是個普通通路權限，如果管理者給100人甚至更多授權,工作量巨大。
這就引入了 "角色(Role)" 概念,一個角色可以與多個使用者關聯,管理者隻需要把該角色賦予使用者,那麼使用者就有了該角色下的所有權限,這樣設計既提升了效率,也有很大的拓展性。
權限 是使用者可以通路的資源,包括頁面權限,操作權限,資料權限:
- 頁面權限: 即使用者登入系統可以看到的頁面,由菜單來控制,菜單包括一級菜單和二級菜單,隻要使用者有一級和二級菜單的權限,那麼使用者就可以通路頁面
- 操作權限: 即頁面的功能按鈕，包括檢視,新增,修改,删除,稽核等，使用者點選删除按鈕時，背景會校驗使用者角色下的所有權限是否包含該删除權限。如果是,就可以進行下一步操作,反之提示無權限。有的系統要求"可見即可操作",意思是如果頁面上能夠看到操作按鈕,那麼使用者就可以操作,要實作此需求,這裡就需要前端來配合,前端開發把使用者的權限資訊緩存,在頁面判斷使用者是否包含此權限,如果有,就顯示該按鈕,如果沒有,就隐藏該按鈕。某種程度上提升了使用者體驗,但是在實際場景可自行選擇是否需要這樣做
-
資料權限: 資料權限就是使用者在同一頁面看到的資料是不同的，比如财務部隻能看到其部門下的使用者資料，采購部隻看采購部的資料。在一些大型的公司，全國有很多城市和分公司，比如杭州使用者登入系統隻能看到杭州的資料，上海使用者隻能看到上海的資料，解決方案一般是把資料和具體的組織架構關聯起來。
舉個例子,再給使用者授權的時候,使用者選擇某個角色同時綁定組織如财務部或者合肥分公司,那麼該使用者就有了該角色下财務部或合肥分公司下的的資料權限。
使用者、角色及權限
以上是RBAC的核心設計及模型分析,此模型也叫做RBAC-0,而基于核心概念之上,RBAC還提供了擴充模式。包括RBAC-1,RBAC-2,RBAC-3模型。下面介紹這三種類型
1.2 RBAC-1模型
image
此模型引入了角色繼承(Hierarchical Role)概念，即角色具有上下級的關系，角色間的繼承關系可分為一般繼承關系和受限繼承關系。
一般繼承關系僅要求角色繼承關系是一個絕對偏序關系，允許角色間的多繼承。
而受限繼承關系則進一步要求角色繼承關系是一個樹結構，實作角色間的單繼承。這種設計可以給角色分組和分層，一定程度簡化了權限管理工作。
1.3 RBAC-2模型
基于核心模型的基礎上，進行了角色的限制控制，RBAC2模型中添加了責任分離關系。
其規定了權限被賦予角色時，或角色被賦予使用者時，以及當使用者在某一時刻激活一個角色時所應遵循的強制性規則。
責任分離包括靜态責任分離和動态責任分離。主要包括以下限制:
- 互斥角色: 同一使用者隻能配置設定到一組互斥角色集合中至多一個角色，支援責任分離的原則。互斥角色是指各自權限互相制約的兩個角色。比如财務部有會計和稽核員兩個角色,他們是互斥角色,那麼使用者不能同時擁有這兩個角色,展現了職責分離原則
- 基數限制:一個角色被配置設定的使用者數量受限；一個使用者可擁有的角色數目受限；同樣一個角色對應的通路權限數目也應受限，以控制進階權限在系統中的配置設定
- 先決條件角色: 即使用者想獲得某上級角色,必須先獲得其下一級的角色
1.4 RBAC-3模型
即最全面的權限管理,它是基于RBAC-0，将RBAC-1和RBAC-2進行了整合。
1.5 使用者組
當平台使用者基數增大，角色類型增多時，而且有一部分人具有相同的屬性，比如财務部的所有員工，如果直接給使用者配置設定角色，管理者的工作量就會很大。
如果把相同屬性的使用者歸類到某使用者組，那麼管理者直接給使用者組配置設定角色，使用者組裡的每個使用者即可擁有該角色，以後其他使用者加入使用者組後，即可自動擷取使用者組的所有角色，退出使用者組，同時也撤銷了使用者組下的角色，無須管理者手動管理角色。
根據使用者組是否有上下級關系,可以分為有上下級的使用者組和普通使用者組:
- 具有上下級關系的使用者組: 最典型的例子就是部門和職位，可能多數人沒有把部門職位和使用者組關聯起來吧。當然使用者組是可以拓展的，部門和職位常用于内部的管理系統，如果是面向C端的系統。比如淘寶網的商家，商家自身也有一套組織架構，比如采購部，銷售部，客服部，後勤部等，有些人擁有客服權限，有些人擁有上架權限等等，是以使用者組是可以拓展的
- 普通使用者組: 即沒有上下級關系，群組織架構，職位都沒有關系，也就是說可以跨部門，跨職位。舉個例子，某電商背景管理系統，有拼團活動管理角色，我們可以設定一個拼團使用者組，該組可以包括研發部的背景開發人員，營運部的營運人員，采購部的人員等等。
每個公司都會涉及到到組織和職位,下面就重點介紹這兩個。
1.5.1 組織
常見的組織架構如
我們可以把組織與角色進行關聯，使用者加入組織後，就會自動獲得該組織的全部角色，無須管理者手動授予，大大減少工作量，同時使用者在調崗時，隻需調整組織，角色即可批量調整。
組織的另外一個作用是控制資料權限,把角色關聯到組織,那麼該角色隻能看到該組織下的資料權限。
1.5.2 職位
假設财務部的職位
每個組織部門下都會有多個職位，比如财務部有總監，會計，出納等職位，雖然都在同一部門，但是每個職位的權限是不同的，職位高的擁有更多的權限。
總監擁有所有權限，會計和出納擁有部分權限。特殊情況下,一個人可能身兼多職。
1.6 含有組織/職位/使用者組的模型
根據以上場景,新的權限模型就可以設計出來了,如下圖:
組織/職位/使用者組
根據系統的複雜度不同,其中的多對多關系和一對一關系可能會有變化
- 在單系統且使用者類型單一的情況下，使用者群組織是一對一關系，組織和職位是一對多關系，使用者和職位是一對一關系，組織和角色是一對一關系，職位和角色是一對一關系，使用者和使用者組是多對對關系，使用者組和角色是一對一關系，當然這些關系也可以根據具體業務進行調整。模型設計并不是死的,如果小系統不需要使用者組,這塊是可以去掉的。
- 分布式系統且使用者類型單一的情況下，到這裡權限系統就會變得很複雜，這裡就要引入了一個"系統"概念。此時系統架構是個分布式系統，權限系統獨立出來，負責所有的系統的權限控制，其他業務系統比如商品中心，訂單中心，使用者中心，每個系統都有自己的角色和權限，那麼權限系統就可以配置其他系統的角色和權限。
- 分布式系統且使用者類型多個的情況下，比如淘寶網，它的使用者類型包括内部使用者，商家，普通使用者，内部使用者登入多個背景管理系統，商家登入商家中心，這些做權限控制，如果你作為架構師，該如何來設計呢?大神可以在評論區留言交流哦!
2.授權流程
授權即給使用者授予角色,按流程可分為手動授權和審批授權。權限中心可同時配置這兩種,可提高授權的靈活性。
- 手動授權:管理者登入權限中心為使用者授權，根據在哪個頁面授權分為兩種方式：給使用者添加角色，給角色添加使用者。給使用者添加角色就是在使用者管理頁面，點選某個使用者去授予角色，可以一次為使用者添加多個角色；給角色添加使用者就是在角色管理頁面，點選某個角色，選擇多個使用者，實作了給批量使用者授予角色的目的。
- **審批授權: **即使用者申請某個職位角色，那麼使用者通過OA流程申請該角色，然後由上級審批，該使用者即可擁有該角色，不需要系統管理者手動授予。
3.表結構
有了上述的權限模型,設計表結構就不難了,下面是多系統下的表結構,簡單設計下,主要提供思路:
image
4.權限架構
- Apache Shrio
- Spring Security
在項目中可以采用其中一種架構,它們的優缺點以及如何使用會在後面的文章中詳細介紹。