RBAC 和 Casbin 的關係？
RBAC大家都知道是一種訪問控制模型，Casbin實現了這個模型，並且還實現了其他很多種訪問控制模型，如ABAC模型。
Casbin 解決了什麼問題？
無需自己從零開始做一套訪問控制系統，比如為使用者新增角色，為角色新增許可權等等介面都已經實現了。這套框架被多種語言實現，並且有多種儲存介面卡。
Casbin 中的概念和 RBAC 的對應關係？
RBAC中的概念很簡單，很容易理解，這裡再贅述一下：角色，使用者，許可權。這三者組合來判斷是否能形成對某一資源擁有訪問資格。
Casbin中的概念雖然比較多（因為這一套框架還要相容其他的訪問控制模型），但是仔細看下去，也是比較容易理解的。
以張三讀取文章介面為例
RBAC的鑑權流程：先看張三的所有身份，再看這些身份下是否擁有讀取文章介面的許可權。
Casbin的鑑權流程：將張三讀取文章介面，抽取三個要素。
第一，操作物件(sub)：張三
第二，動作(act)：讀取
第三，資源(obj)：文章介面
將這三要素組合成一組請求r，拿著這組請求和已有的策略p，去某個列表裡按某種匹配規則m進行匹配，匹配後的結果傳入到影響 e中，看是否透過。（別急，下面有解釋）。
以上涉及到了幾個 Casbin 的重要概念，sub，act，obj，r，p，m，e。其中sub可以是單使用者，也可以是角色。其中p，m，e，相對於RBAC模型中我們可能很少遇到。
下面將對以上概念進行解釋。
r：請求，由上述三要素組成，格式與
p一致。可以理解為入口函式。
p：策略=
{sub,obj,act}，會有一個策略列表（可以簡單地理解為等同於 RBAC 中角色和許可權的關係表）。通常我們如果僅用RBAC的話，理解到這裡就可以了，後面其實還可以有一個引數，可以簡單地理解為禁用（即該操作物件不能操作此資源），黑名單，表示這一組策略被拉黑或者透過，預設為透過。
m：
m解決的是p和r如何進行匹配的問題，是匹配規則，僅返回是否匹配中 。可以理解為如何找到策略列表中對應的規則。
比如在此項中，我們可以加入超級管理員的角色的匹配規則，即使沒有匹配中常規規則，但如果你是超級管理員的話，也預設為匹配中了。
e：影響。僅做最終對匹配結果後的處理，即最終由這裡返回是否透過。只可能有四種（官網有）。可以理解為最後的判斷規則。為什麼會有這個呢？按道理來說僅有
m就夠了啊？
實際上還是因為上面說過的原因，因為Casbin做的不僅是簡單RBAC，在其他或者更高階的RBAC中，可能會出現有一條策略匹配中了，同時也還匹配上了另外一條策略，但是後一條策略表達的是該使用者不能使用此資源，問題就來了，一條允許，一條不允許，那到底是通不透過呢？這時e就發揮了作用，你既可以在此項設定所有策略都透過即為透過，也可以設定為有一條透過即為透過。
沒有涉及到的概念：角色域。g=使用者,角色。這個是用於多租戶（多商戶）模型的許可權控制系統，這裡不表。
其他概念和我的經驗？
先簡單瞭解一下，做的過程中大致流程和概念及要注意的點，這些清楚後我們就只是呼叫介面的事了。
兩個檔案
Casbin 官網中可以看到，初始化時，涉及到了兩個檔案，一個是模型配置檔案model.conf，一個是策略檔案。
模型檔案中，可以定製上述概念的各種組合，比如說m中的超級管理員，e中的到底通不透過問題，別擔心，這個或許真的不用存到資料庫中，一般定下來就不會動了的。
策略檔案，我們就還是算了吧，儲存到資料庫中，更方便我們管理，Casbin中有各種儲存介面卡，我使用的是grom的介面卡。
注意點
在官網中，
Casbin明確指出，使用者表和角色表，應當由專案自己管理，Casbin只做許可權控制。當我們使用
grom介面卡時，初始化Casbin的時候，會預設建立一張表casbin_rules，這裡面可以儲存使用者和角色的關係，角色和許可權的關係。（這裡只說使用Casbin的RBAC模型）上兩點可以得知，使用者表，角色表，許可權表，我們無論從業務角度還是
Casbin的限制，都應該我們自己來建立管理。官方文件中，會存在一些錯誤，有時候我們還是需要讀一下
Casbin和介面卡的原始碼，究竟該如何使用這些介面，甚至說看這些介面有沒有。一定要注意Casbin和介面卡的版本，不然可能跟文件對不上。Casbin為了效能考慮，會將一些資料載入記憶體中。所以，當專案重啟時，一定要記得將casbin_rules那張表載入到記憶體中去，即初始化Casbin時，呼叫LoadPolicy()。在我們刪除或修改使用者，角色，許可權時，記得想一下，
casbin_rules那張表需不需要動呢？如果要動，可以去官網文件中找到對應介面。我的實踐，在
casbin_rules中，角色和使用者，我均只儲存角色 id 和使用者 id ，角色和許可權的對應關係中，角色我存 id，許可權通常是路由地址，因為檢查許可權通常是讀多寫少，這樣做的好處是請求來時可以直接透過路由地址和使用者 id 檢驗許可權，不用自己再到資料庫中查到路由地址 id 後再去查許可權。
2022-10-25 對上面第七點進行勘誤。因為Casbin獲取使用者下的所有許可權，和獲取角色下的所有許可權使用的是同一個介面（在資料層面均當成一個普通字串處理），所以儲存角色id，最好加一個字首或字尾。這樣可以避免你傳入一個使用者id，它取出了一個和你給的使用者id一樣的角色id，擁有的許可權。
具體程式碼什麼的很簡單，就是純呼叫介面。在這裡我就不貼出來了，相信看到這裡，再結合看一下Casbin文件，大家都能寫出來。以上是我最近學習使用 Casbin的經驗教訓和總結，希望對大家有幫助。
本作品採用《CC 協議》，轉載必須註明作者和本文連結