任何應用，都會涉及到用戶權限管理的問題。RBAC 授權模型，即基于角色的訪問控制，是指根據用戶在組織中的角色為用戶分配權限。

使用 RBAC，只要嚴格遵守角色的規則要求，它會讓你的訪問管理變得非常容易，且不容易出錯。

在大中型企業的實踐中， RBAC 授權模型已經被認為是最佳的員工授權管理解決方案。

例如，您使用 RBAC 來控制 HR 應用程序的訪問權限，您可以為 HR 經理提供一個角色，允許他們更新員工詳細信息，而其他員工只能查看他們自己的詳細信息。

接下來，我們為您做詳細的解答。

RBAC 模型是什么?

美國國家標準與技術研究院（The National Institute of Standards and Technology）認為 RBAC 模型由 4 個基礎模型組成：

1. 基本模型 RBAC0（Core RBAC）

2. 角色分層模型 RBAC1（Hierarchal RBAC）

3. 角色限制模型 RBAC2（Constraint RBAC）

4. 統一模型 RBAC3（Combines RBAC）

RBAC 授權的過程可以抽象概括為：判斷 Who 是否可以對 What 進行 How 的訪問操作，以及這個邏輯表達式的值是否為 True 的計算過程。

Who、What、How 構成了訪問權限三元組，Who 是權限的擁有者或主體（User、Role），What 是資源（Resource），How 是具體的權限。

RBAC 模型有什么特點?

RBAC 授權模型，最根本的初衷是簡化權限管理，后來被越來越多的企業應用到了員工授權資源管理系統中。

隨著用戶的規模和復雜性增加，角色會變得非常有用。比如，將特定角色添加到特定組織成員中，并允許組織成員訪問特定的程序。這在支持多租戶和 SaaS 產品時特別有用，其中特定用戶可能在一個組織中擁有特權角色，但在其他組織中沒有。

RBAC 模型的優勢：

• 減少授權管理的復雜性，降低管理成本；
• 創建系統的、可重復的權限分配；
• 輕松審核用戶權限并糾正已發現的問題；
• 快速更改角色，以及跨 API 實施角色；
• 減少分配用戶權限時出錯的可能性；
• 靈活地支持企業的安全策略，并且有很大的伸縮性；
• RBAC 適用于多對多的映射關系。

RBAC 模型的缺點：

RBAC模型沒有提供操作順序控制機制。這一缺陷使得 RBAC 模型很難應用于那些要求有嚴格操作次序的實體系統。

例如，公司采購流程就沒有辦法用 RBAC 模型授權控制采購過程中每一個流程中應該怎么樣授權。

基本模型 RBAC0

RBAC0 是最基礎也是最核心的模型，由五部分組成：用戶（User）、角色（Role）、許可（Permission）、會話（Session）、操作（operations OPS）。

角色通過許可被授權資源，角色又授權到用戶身上，通過會話管理用戶和角色的授權關系，用戶就繼承了角色的訪問資源權限。

例如：張三是一家企業的財務總監，同時他也是該企業對外的形象大使，財務總監有訪問公司財務數據的權限，形象大使有訪問公司市場部推廣計劃和編輯發言稿的權限。那么張三既有訪問公司財務數據的權限，又有訪問公司市場部推廣計劃和編輯發言稿的權限。突然有一天公司決定做職位調整，張三被任命為財務總監和人力資源總監，撤掉了形象大使。那么張三當前就只能訪問財務總監和人力資源總監所對應的授權資源。

角色分層模型 RBAC1

該模型主要是在 RBAC0 的基礎上，增加了角色層級關系的繼承邏輯，也就是說角色有了組織樹的邏輯。

角色有了上下級關系，上一級的角色可以繼承其下所有角色的授權資源。

例如：張三是一家企業的財務總監，同時他也是該企業對外的形象大使，財務總監有訪問公司財務數據的權限，形象大使有訪問公司市場部推廣計劃和編輯發言稿的權限。那么他的上級領導，比如是該公司的 CFO，既有訪問公司財務數據的權限，又有訪問公司市場部推廣計劃和編輯發言稿的權限。這是繼承關系。

角色限制模型 RBAC2

該模型主要添加了授權約束。約束規定了權限被賦予角色時，或角色被賦予用戶時，以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。

責任分離包括：靜態責任分離（SSD）和動態責任分離（DSD）。

SSD 是用戶和角色的指派階段加入的，主要是對用戶和角色有如下約束:

互斥角色：同一個用戶在兩個互斥角色中只能選擇一個。比如財務部有會計和審核員兩個角色，他們是互斥角色，那么用戶不能同時擁有這兩個角色，體現了職責分離原則。

基數約束：一個角色被分配的用戶數量受限，一個用戶可擁有的角色數目受限，同樣一個角色對應的訪問資源權限數目也受限，以控制高級權限在系統中的分配。比如李四是 COO，王五不能也是 COO。同樣的李四不能既是 COO 又是 CTO 又是 CFO。COO 、CTO、 CFO 三個角色所能訪問的資源權限也不能是一模一樣的。

先決條件約束：用戶想要獲得高級角色，首先必須擁有低級角色。

DSD 是會話和角色之間的約束，可以動態的約束用戶擁有的角色。

如一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。如一個人如果既是運動員又是教練，當比賽開始的時候，只能選擇一個角色身份入場。

統一模型 RBAC3

RBAC3 是 RBAC1 與 RBAC2 的合集，所以 RBAC3 是既有角色分層又有約束的一種綜合授權模型。

 

Authing 基于角色的訪問控制

Authing 的授權模型是在 RBAC3 的基礎上，改進的一種授權模型。提高了性能和可擴展性，主要由用戶、組織、租戶角色、應用角色、資源等模塊進行交叉管理，最終提供更加靈活、適用范圍更廣泛的 RBAC 系統。

Authing RBAC 可適用的場景非常多，舉兩個典型場景示例：

場景一：A 公司旗下有 3 個子公司（假定 3 個子公司分別為 A1、A2、A3），每個子公司都有自己的組織架構和相對應不同的資源訪問權限。該公司希望通過 Authing 可以統一的管理這三家公司之間人員交叉訪問資源的授權問題。

我們最終實現，A1 公司的員工只需要登錄 Authing 一次，就可以在訪問 A2 公司資源的時候，系統給他的權限是這個員工對應在 A2 公司的角色權限；而且還可以限定很多附加條件，在該員工全部滿足以后才可以拿到 A2 公司的資源；幫助 A 公司實現了集團型公司統一的權限分配管理。

場景二：X 應用在最初設計的時候沒有考慮到多個用戶組訪問資源時，如何解決不同用戶組之間和用戶組內部的交叉授權資源的關系。

我們最終實現，用戶組 A 和 B 訪問 X 應用的時候，資源隔離，并且 A1 用戶可以被授權訪問 B1 用戶的部分資源的需求。

Authing RBAC 權限模型的可拓展性

Authing 在基于角色資源授權上有非常豐富的模型設計，將用戶、角色、資源這三個權限模型 “源” 進行非常精細的劃分和管理，讓授權管理這件事變得像拼積木一樣靈活便捷，能夠應對各種復雜的場景。

您可以點擊閱讀原文，了解如何使用 Authing API ，為您的應用配置合適的權限模型。