一、什么是ABAC訪問控制模型
基於屬性的訪問控制（Attribute-Based Access Control，下文簡稱ABAC）是一種靈活的授權模型。是通過實體的屬性、操作類型、相關的環境來控制是否有對操作對象的權限。
例如：P5（職級）的同學有OA系統的權限。
上述是一個簡單的ABAC的例子，就是通過實體的職級這一屬性來控制是否有OA系統的權限
再比如：P5（職級）的研發（職位）同學有公司Gitlab的權限
上述例子是通過一組實體的屬性（職級和職位）來控制對操作對象的權限
再比如：P5（職級）的研發（職位）同學在公司內網（環境）可以查看和下載（操作）代碼。
上述例子顯然比之前兩個更加復雜，除了判斷實體的屬性（職級和職位），還判斷了當前的環境屬性和操作屬性
所以我們可以ABAC的訪問控制模型用下面這張圖表現出來
ABAC的使用場景
ABAC授權模型理論上能夠實現非常靈活的權限控制，幾乎能滿足所有類型的需求。從使用場景來說比較適用於用戶數量多並且授權比較復雜的場景。簡單的場景也是可以使用ABAC的，但是使用基礎的ACL或者RBAC也能滿足需求。
場景一：
還是拿上面的例子來說：P5（職級）的研發（職位）同學在公司內網（環境）可以查看和下載（操作）代碼。
在需要根據環境屬性和操作屬性來動態計算權限的時候，使用其他的授權模型可能不太能滿足需求。這個時候就需要使用ABAC授權模型。
場景二：
ABAC也適用於公司成員（角色）快速變化的場景，由於ABAC 是通過用戶的屬性來授權的。在新建用戶/修改用戶屬性時會自動更改用戶的權限，無需管理員手動更改賬戶角色。
在屬性的組合比較多，需要更細粒度地划分角色的情況下。RBAC需要建立大量的角色。ABAC授權模型會更加靈活。
二、與RBAC訪問控制模型的對比
ABAC對於RBAC有以下優點
- 對於大型組織，基於RBCA的控制模型需要維護大量的角色和授權關系，相比而言，ABAC更加靈活；對於中小型組織，維護角色和授權關系的工作量不大，反而定制各種策略相對麻煩，更容易接受RBAC授權模型。
- 新增資源時，ABAC僅需要維護較少的資源。而RBAC需要維護所有相關的角色。ABAC可擴展性更強、更方便。
- RBAC支持帶有動態參數的授權規則，RBAC只能基於靜態的參數進行判斷。
- ABAC權限控制的粒度比RBAC更細。
-
補上RBAC的另外幾種延伸形式
1、RBAC-1
RBAC1引入角色間的繼承關系，角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系僅要求角色繼承關系是一個絕對偏序關系，允許角色間的多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構。
2、RBAC-2
RBAC2模型中添加了責任分離關系。RBAC2的約束規定了權限被賦予角色時,或角色被賦予用戶時,以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。
責任分離包括靜態責任分離和動態責任分離。靜態責任分離
1、互斥角色限制：同一個用戶在兩個互斥的角色中只能選擇一個
2、角色數量限制：一個用戶擁有的角色數是有限的，同樣的權限也會是有限的
3、角色先后限制：用戶要擁有更高級的角色，首先要有相應的低級角色
動態責任分離
4、角色激活限制：如一個用戶允許擁有兩個角色，但運行時只能激活一個角色約束與用戶-角色-權限關系一起決定了RBAC2模型中用戶的訪問許可。
3、RBAC-3
RBAC3包含了RBAC1和RBAC2，既提供了角色間的繼承關系，又提供了責任分離關系。