Refer to
https://blog.csdn.net/m0_37163942/article/details/83652065
ACL（Access Control List）:訪問權限列表 如：
user1-->AC1
user1-->AC2
user2-->AC1 此時權限匯總成一個列表
這種設計最常見的應用就是文件系統的權限設計，如微軟的NTFS
對權限控制比較分散，不便於管理，比如無法簡單地將一組文件設置統一的權限開放給指定的一群用戶
RBAC(Role Base Access Control):基於角色的權限控制
與ACL 對比 RBAC不用給用戶單個分配權限，只用指向對應的角色就會有對應的權限，而且分配權限和收回權限都很方便
如菜單權限的設計：用戶與角色關聯，角色與菜單關聯
ABAC（Attribute Base Access Control） 基於屬性的權限控制
不同於常見的將用戶通過某種方式關聯到權限的方式，ABAC則是通過動態計算一個或一組屬性來是否滿足某種條件來進行授權判斷（可以編寫簡單的邏輯）。屬性通常來說分為四類：用戶屬性（如用戶年齡），環境屬性（如當前時間），操作屬性（如讀取）和對象屬性（如一篇文章，又稱資源屬性），所以理論上能夠實現非常靈活的權限控制，幾乎能滿足所有類型的需求。
例如規則：“允許所有班主任在上課時間自由進出校門”這條規則，其中，“班主任”是用戶的角色屬性，“上課時間”是環境屬性，“進出”是操作屬性，而“校門”就是對象屬性了。為了實現便捷的規則設置和規則判斷執行，ABAC通常有配置文件（XML、YAML等）或DSL配合規則解析引擎使用。XACML（eXtensible Access Control Markup Language）是ABAC的一個實現，但是該設計過於復雜，我還沒有完全理解，故不做介紹。
總結一下，ABAC有如下特點：
集中化管理
可以按需實現不同顆粒度的權限控制
不需要預定義判斷邏輯，減輕了權限系統的維護成本，特別是在需求經常變化的系統中
定義權限時，不能直觀看出用戶和對象間的關系
規則如果稍微復雜一點，或者設計混亂，會給管理者維護和追查帶來麻煩
權限判斷需要實時執行，規則過多會導致性能問題
既然ABAC這么好，那最流行的為什么還是RBAC呢？
我認為主要還是因為大部分系統對權限控制並沒有過多的需求，而且ABAC的管理相對來說太復雜了。Kubernetes便因為ABAC太難用，在1.8版本里引入了RBAC的方案。
ABAC有時也被稱為PBAC（Policy-Based Access Control）或CBAC（Claims-Based Access Control）