如何基於RBAC設計模型設計許可權管理系統
1.什麼是RBAC
RBAC是取自（Role-Based Access Control)四個單詞首字母的縮寫成的名稱或者術語，意思是基於角色訪問控制，它是基於角色為核心去關聯許可權進行訪問控制的一種許可權設計模型。
1.1.RBAC和許可權管理系統有什麼關係
現在比較普遍的許可權管理系統都是基於RBAC許可權設計模型進行設計的，RBAC設計模型是許可權管理系統的一種策略，或者說許可權管理系統是RBAC許可權設計模型的具體實現。
1.2.什麼是許可權
許可權是使用者可以訪問的資源,包括頁面許可權,操作許可權,資料許可權。
舉個例子：在常規的管理系統中，使用者張三登入系統後對個人資訊進行修改，那它能看到的個人資訊頁面
修改個人資訊按鈕、個人資訊資料這三者都是許可權，分別對應頁面、操作、資料許可權。
1.3.什麼是角色
按照我個人理解是角色是擁有特定功能或者承擔特定責任的人或者使用者。
舉個例子：登入管理系統的張三，在公司是管理系統中管理員，同時他又是開發該管理系統的開發者。那麼張三擁有管理員、開發者兩個角色。
管理員有負責管理系統的使用者功能，開發者有開發系統的責任。
1.4.什麼是訪問控制
訪問控制就是什麼人能幹什麼事，還是以管理系統為例子說明。
李四是個普通使用者，沒有其他角色，那麼他只能修改到自己的個人資訊。
張三是個管理員，他能修改到自己的個人資訊，同時可能還可以修改李四的個人資訊，還可以新增其他使用者，刪除其他使用者。
李四不能修改張三個人資訊，張三能修改李四資訊，這就是什麼人能幹什麼事，也就是訪問控制。
1.5.不基於RBAC設計許可權管理系統缺點
如果不基於角色關聯許可權進行訪問控制設計許可權管理系統，而是基於使用者-許可權設計訪問控制會有什麼問題？
在使用者數量比較小的管理系統,比如10個人左右的管理系統,張三管理員可以直接把使用者和許可權關聯,工作量並不大,選擇一個使用者勾選下需要的許可權就完事了。
假設一個使用者有4個許可權，兩個使用者就需要勾選8次才能完成授權。
但是在實際企業管理系統中,使用者數量比較大,其中很多人的許可權都是一樣的,就是個普通訪問許可權,這個普通訪問許可權有100個許可權，如果管理員給100人授權,100*100 = 10000個許可權，那麼他授權的工作量就是非常巨大的
這就引入了"角色(Role)"概念,一個角色可以授予相同100個普通許可權，一個角色可以與100個使用者關聯。
管理員只需要把該角色賦予使用者,那麼使用者就有了該角色下的所有許可權,這樣設計既提升了效率,也有很大的拓展性。
同時我們解除授權也很簡單，比如王五解除授權，只需要將王五和普通使用者的角色關係一斷開，就立即可以完成解除授權。
2.RBAC模型資料庫表設計
2.1.使用者角色許可權之間的關係
在前面提到，一個使用者是可以有多個角色，一個角色是可以有多個許可權的。所以三者之間的關係從全域性來說都是多對多關係。
2.2.使用者和角色是一對一關係表設計
在實際的開發中，對於角色和許可權的數量關係來說，角色相對會比許可權數量少一點。對於使用者和角色的數量關係來說，角色相對會比使用者數量少一點。那麼我們將它們之間的關係設計為：一個使用者一個角色即一對一關係，角色和許可權之間是多對多關係。
這也是為什麼RBAC設計模型是以角色為核心去圍繞展開設計的
設計中需要考慮的點是外來鍵關係，實際開發中很少建立真正的外來鍵關係，只是建立相應的外來鍵列，通過關聯查詢連線在一起即可。
但最關鍵的點是外來鍵FK的維護應該放在數量多的一方，比如使用者和角色兩張表，實際中肯定角色會少一點，而使用者數肯定隨時間變化越來越多。所以使用者和角色的外來鍵關係維護，是放在使用者表這一邊。
如果不能理解這一點，可以想想，在公司中讓員工記住老闆容易還是老闆記住員工簡單這個例子，很明顯員工數肯定多於老闆數量，所以肯定是員工記住老闆來得容易。
2.3.使用者和角色是多對多關係表設計
還有一種表設計是允許一個使用者有多個角色，比如前面提到的張三既是管理系統的管理員又是管理系統的開發者。基於這樣的使用場景下，如果有多個使用者像張三這樣，那麼就演變成使用者和角色是多對多關係，而角色和許可權是多對多關係維持不變。
這時候我們只需要在使用者和角色之間新增一張中間表，用來維護它們之間的多對多關係即可。不知道你們有沒有發覺到，凡是需要建立多對多關係，都需要建立一張中間表來維護。
如果沒有發覺，可以回顧以下，上面使用者和角色關係是一對一關係的表設計中，角色和許可權是不是也是綠色的，它們之間是不是也靠中間表來連線起來。
2.4.RBAC表及欄位設計小結
上面只是列出比較常用的兩種表設計，並且列出比較關鍵的欄位，在實際開發中，肯定不止這些欄位。
比如使用者表可能會有建立人，建立時間，更新人，更新時間等等基本資訊。
比如許可權表可能又可以拓展細分成多張表，劃分選單許可權，介面Api許可權等表
但只要掌握基礎的RBAC設計模型，後面的拓展基本上就依葫蘆畫瓢，能很好理解上手，只不過需要的是一些時間、以及抽象的經驗。
3.RBAC模型劃分
前面提到是最基礎的RBAC模型，而基於核心概念之上,RBAC還提供了擴充套件模式。包括RBAC1,RBAC2,RBAC3模型。下面介紹這三種類型
3.1.RBAC1模型
此模型引入了角色繼承(Hierarchical Role)概念,即角色具有上下級的關係,角色間的繼承關係可分為一般繼承關係和受限繼承關係。
一般繼承關係僅要求角色繼承關係是一個絕對偏序關係，允許角色間的多繼承。而受限繼承關係則進一步要求角色繼承關係是一個樹結構，實現角色間的單繼承。這種設計可以給角色分組和分層，一定程度簡化了許可權管理工作。
3.2 RBAC2模型
基於核心模型的基礎上，進行了角色的約束控制,RBAC2模型中添加了責任分離關係,其規定了許可權被賦予角色時，或角色被賦予使用者時，以及當用戶在某一時刻啟用一個角色時所應遵循的強制性規則。責任分離包括靜態責任分離和動態責任分離。主要包括以下約束:
- 互斥角色: 同一使用者只能分配到一組互斥角色集合中至多一個角色，支援責任分離的原則。互斥角色是指各自許可權互相制約的兩個角色。
比如財務部有會計和稽核員兩個角色,他們是互斥角色,那麼使用者不能同時擁有這兩個角色,體現了職責分離原則
-
基數約束: 一個角色被分配的使用者數量受限；一個使用者可擁有的角色數目受限；同樣一個角色對應的訪問許可權數目也應受限，以控制高階許可權在系統中的分配
-
先決條件角色: 即使用者想獲得某上級角色,必須先獲得其下一級的角色
3.3. RBAC3模型
即最全面的許可權管理,它是基於RBAC0,將RBAC1和RBAC2進行了整合
4.RBAC落地實現和總結
Apache Shrio和Spring Security都是對RBAC許可權設計能提供落地實現的框架，在企業級專案中許可權管理系統都有用到，
Apache Shrio比較輕量級，不用配置很多，學習成本較低。
Spring Security是在當下SpringBoot、微服務以及前後端分離流行下，比較熱門的的安全認證框架。
兩者都值得學習和比較，以便應對不同場景下能夠快速選型合適技術，本文也是在我在學習兩個框架之時，對RBAC模型覺得比較難理解，所以寫下這篇博文，來幫助自己理解之間的關係。
同時也算是一點經驗分享給需要學習這兩個框架的人，最好在學習兩個框架之前能稍微懂RBAC模型才能較好理解裡面的知識內容。