編輯導語：權限配置能力，可以為各應用提供權限配置原子能力，幫助應用快速集成權限配置，提高系統權限管理體驗。本文作者分析了如何以RBAC模型設計可配置的權限中心，一起來看一下吧。

權限配置能力作為權限控制器，為各應用提供權限配置原子能力。這裡聊聊，如果想要以RBAC模型設計可配置的權限中心，該怎麼入手。

筆者根據自己的行業經驗總結了一下思路，歡迎大家批評指正。

所謂權限配置能力，就是以權限、角色為中心，把權限配置單獨作為原子能力服務，高度抽象，為開發者、運營人員提供一整套對菜單、接口和數據資源進行授權，同時提供标準授權界面，幫助應用快速集成權限配置，為業務運營集成權限統一管理，形成标準化流程，提高系統權限管理體驗。

權限配置能力，主要實現的是從用戶角色到功能應用的權限控制器，提供管理功能權限、數據權限的基礎能力，提供權限服務（管理 控制）能力給每一個應用使用，免除重複開發、考慮不全的問題。

一、什麼是RBAC模型

首先，我們來說說什麼是RBAC模型。

RBAC認為權限授權的過程可以抽象地概括為：Who是否可以對What進行How的訪問操作，并對這個邏輯表達式進行判斷是否為True的求解過程，也即是将權限問題轉換為What、How的問題，可以說，Who、What、How構成了訪問權限三元組。

1. RBAC的組成

在RBAC模型裡面，有3個基礎組成部分，分别是：用戶、角色和權限。

RBAC通過定義角色的權限，并對用戶授予某個角色從而來控制用戶的權限，實現了用戶和權限的邏輯分離（區别于ACL模型），極大地方便了權限的管理。

• 用戶-角色映射：用戶和角色之間的映射關系
• 角色-權限映射：角色和權限之間的映射關系

（注：圖來源于網絡，如侵權可告知删除）

2. RBAC的原則

RBAC支持三個著名的安全原則：最小權限原則、責任分離原則和數據抽象原則。

• 最小權限原則：RBAC可以将角色配置成其完成任務所需的最小權限集合。
• 責任分離原則：可以通過調用相互獨立互斥的角色來共同完成敏感的任務，例如要求一個計賬員和财務管理員共同參與統一過賬操作。
• 數據抽象原則：可以通過權限的抽象來體現，例如财務操作用借款、存款等抽象權限，而不是使用典型的讀、寫、執行權限。

3. RBAC的優缺點

RBAC模型優點是簡化了用戶和權限的關系易擴展、易維護。

但也存在一定的局限性，比如，RBAC模型沒有提供操作順序的控制機制，這一缺陷使得RBAC模型很難适應哪些對操作次序有嚴格要求的系統。

二、權限控制框架

聊完了RBAC模型，我們可以先看看權限控制框架設計。

剛剛提到過，所謂權限，就是對資源、數據等進行配置，不同的人分配不同的權限。可以說，權限控制框架其實就是将不同的資源、數據分配給不同的角色，從而完成授權行為。

1. 權限配置

針對不同的角色配置相應的授控資源（包括菜單、接口、數據資源等）完成授權配置。

具體配置流程需要對應用系統的資源進行錄入（包括菜單資源、接口資源、數據資源）後，對業務應用系統的資源進行重新配置為權限策略，最後對角色進行賦權以及角色綁定用戶。

完成配置後，業務系統通過調用對外服務的SDK标準組件或接入API接口，判斷資源與用戶/角色的關聯關系後進行權限控制即可。

實際上，授權不僅僅可以對角色進行授權，實際上還可以通過将角色與組織機構、行政區劃、标簽等緯度進行關聯授權，甚至是直接将用戶與組織機構、行政區劃、标簽等緯度進行關聯授權。但在本文中，暫時先不考慮這種多維度的授權邏輯，隻讨論常規授權邏輯。

2. 鑒權服務

針對具體的運行環境，判斷授權對象是否對授控資源具有某種操作或數據範圍的權限。

三、資源管理

權限策略的前提時，需要對應用系統的資源（包括菜單資源、接口資源、數據資源）進行錄入。

在系統初始化時，由超級管理員或開發人員完成碼資源管理的錄入和管理，後續可集成到相應的管理平台中，為産品運營提供靈活可控的權限控制。

1. 菜單資源

菜單資源，指的是對業務系統的前端功能菜單/頁面資源進行錄入管理，以獨立的URL進行區分，可進行分層級管理。

• 新增菜單資源：需要填寫資源名稱、資源編碼、資源路徑、排序号、打開方式等信息
• 新增子菜單：需要填寫資源名稱、資源編碼、資源路徑、菜單等級和上級菜單、排序号、打開方式等信息
• 查詢：比如可根據菜單名稱、ID等進行搜索
• 編輯：編輯菜單資源的基本信息，這裡需要注意的是，要确定資源的唯一性及是否可修改等等
• 删除：删除菜單資源，可設置一定的校驗規則，比如需要删除下級菜單，才可以删除上級菜單
• 批量導入：可按照标準文檔要求，批量導入菜單信息

2. 接口資源

接口資源，指的是對業務系統的後端接口資源進行錄入、管理，可以錄入URL關鍵字段和接口請求方式。

• 新增接口資源：需要填寫選擇資源名稱、資源編碼、資源路徑、請求方式等
• 查詢：比如根據接口名稱、接口地址進行搜索
• 編輯：編輯接口資源
• 删除：删除接口資源
• 批量導入：可按照标準文檔要求，批量導入接口信息

3. 數據資源

數據資源，主要指業務系統中存儲的數據資源，通過字段信息進行區分，可以通過唯一編碼錄入權限管理。

• 新增數據資源：需要填寫選擇數據元素名稱、元素編碼、所屬頁面名稱、所屬菜單路徑等
• 查詢：比如根據字段名稱進行搜索
• 編輯：編輯數據字段資源
• 删除：删除數據字段資源
• 批量導入：可按照标準文檔要求，批量導入字段信息

四、權限策略

根據業務應用實際情況，建立權限策略管理功能，對已經納入管理的資源，包括資源管理添加的菜單、接口、數據字段資源進行重新配置權限，管理權限與資源的關聯邏輯。

從控制力度來看，權限管理分為兩大類：功能權限管理和數據權限管理。

在系統初始化時，由超級管理員或開發人員完成碼權限策略的配置和管理，後續可集成到管理平台中，為産品運營提供靈活可控的權限控制。

1. 功能權限

1）定義

通俗的說，功能權限指用戶登錄系統後能看到哪些模塊，操作哪些按鈕。每個角色有配置固定的功能權限，角色之間權限相互隔離。所有角色的對應功能權限由管理後台進行配置。

2）分類

功能權限包括：業務功能、授權功能。

• 業務功能：根據業務場景，定義不同的業務功能。結合實際業務場景，進行業務功能與角色關聯配置，完成相關角色的權限配置。
• 授權功能：若該角色具有“授權管理”功能，則需要通過管理後台配置允許該角色進行授權的子角色。

2. 數據權限

1）定義

如果所有信息都是公開透明的，也就不需要做數據權限的控制。可城市碼的業務形态多而雜，每個人、每個角色需要看到的、應該看到的數據不同，數據權限便應這些需要和規則而生。

數據權限較比于其他兩個權限較為抽象，指的是用戶是否有針對某些數據的浏覽權限，用戶在某個模塊裡能看到哪些範圍的數據。不同角色在同一個頁面看到的信息是不同的，可以通過組織架構來區分。

2）業務決定

對于數據權限的管理比較複雜，這個主要還是有具體的業務來決定的。數據權限一般和組織架構相關。根據組織機構的層級關系，結合業務實際場景，實現不同角色的數據權限的劃分。

比如A業務經理隻能看到自己的客戶數據，但是A的業務總監可以查看到各個區域業務員的客戶數據。

3）數據權限向上兼容原則

數據權限向上兼容，若出現多層級授權場景，上級可以對查看下級信息（包括統計信息、授權信息等）。當用戶獲取數據時，根據自己當前的部門和職位，獲取到所有下屬的職員信息。

例：業務管理員可以查看其管轄範圍内次級管理員或業務員的所有信息。

3. 權限策略

對已經在【資源管理】已經錄入的資源，在【權限策略】進行重新配置為權限策略。

• 新增權限策略：需要填寫功能名稱、功能URL路徑、功能描述、行政區劃、組織機構等，對【權限策略列表】進行勾選
• 查看：對已授權功能進行展示，并可以展開查看所有資源明細
• 編輯：編輯功能權限
• 删除：删除功能權限
• 關聯角色：關聯角色，對角色進行賦權

五、角色管理

在系統初始化時，由超級管理員或開發人員完成角色管理的配置和管理，後續可集成到管理平台中，為産品運營提供靈活可控的權限控制。

1. 角色授權

在功能權限策略管理功能已經完成功能權限配置後，需要對角色進行賦權，賦權後展示角色對已授權功能權限和資源明細全景圖，便于配置維護。可将角色與用戶進行綁定，完成角色授權。

• 新增角色：需填寫角色的名稱、角色類型、角色層級（行政區劃、組織機構）
• 編輯角色：編輯角色
• 關聯權限：關聯權限策略，對角色進行賦權
• 關聯用戶：将角色與用戶關聯起來，從而實現對用戶授權

2. 角色的組織屬性

1）行政區劃

行政區劃是行政區域劃分的簡稱，是國家為了進行分級管理而實行的區域劃分。一般來說，我國的行政區劃管理體系顆粒度可到省-市-區-街道-社區村居5級管理。

一個管理員隻對應一個行政區劃，管理員下的查驗員都跟着管理員的行政區劃。

注意：很多時候，行政區劃不是必要的組織屬性，一般的to B企業基本不會用到該字段信息。但有時候對于政務行業相關的應用系統，行政區劃信息還是必要的。

2）組織架構

組織機構是行政組織機構管理的簡稱，是為了實現在不同組織機構、部門等層級的分級管理設計。根據組織機構的層級關系，結合業務實際場景，實現不同角色的功能權限、數據權限的劃分。

3. 角色層級

1）定義

角色層級可配置3-5個層級，包括普通用戶、管理端的管理人員和業務角色。所有角色根據不同場景、不同業務需求決定，角色之間的授權限制條件也與業務場景相關。

2）分類

角色可以分為管理角色、業務角色。

• 管理角色：具備數據查看權限、具備授權功能，同時也可以擁有業務角色的功能權限
• 業務角色：具備業務功能，根據實際業務場景判斷是否具備授權功能（一般不具備）

3）角色權限說明

所有角色與用戶的關聯可通過管理後台進行授權操作。

六、用戶賦權

1. 用戶管理

用戶管理當前提供後台系統賬号的新增和批量導入功能，添加用戶時需要添加用戶的業務屬性，包括角色和角色權限。

2. 用戶授權

通過管理後台或小程序，将用戶與角色綁定關聯，實現用戶賦權。一旦用戶被分配了适當的角色後，該用戶就擁有此角色的所有操作權限。

用戶與角色是多對多的關系。一個用戶可以擁有若幹角色，一個角色也可以賦予若幹用戶。

3. 多角色并存機制

多個角色并存的時候，不同角色的擁有不同功能權限的功能模塊。這裡需要分兩種情況進行分析。

1）角色權限向上兼容原則

用戶可以通過角色切換來進行功能模塊的切換，但角色權限也存在向上兼容原則，也就是說，高級權限可以覆蓋低層級權限。

比如，一個用戶可能即是公司員工又是管理人員，那麼這時候他既有普通員工的角色權限，也有管理層（比如業務經理）的角色權限，這時候他登錄時無需進行角色切換，而是直接以他所擁有的最高層級角色登陸系統，顯示他最高層級角色的功能頁面即可。

2）角色權限無法兼容

但也會存在另一種情況，就是可能在系統内，某個用戶他既是财務人員，又身兼監管部門要職，而這兩種角色的功能業務可能會存在某種沖突，系統不允許同一用戶同時兼容這兩種身份，但實際上企業内部又出現了這種情況。那麼我們就得對這兩種角色的權限進行隔離，讓同一用戶能在系統中身兼多任（注：這裡提供的案例可能不是非常準确）。

這裡提供一個筆者的解決方案，各位如果有更好的解決思路，歡迎補充~

當面臨這種角色權限無法兼容時，可以通過角色切換實現對角色權限的隔離。比如：

若用戶隻有1個角色或同時擁有2哥及以上的角色但角色可向上兼容，登錄時默認使用該用戶最高層級的角色登錄，加載最高層級角色的功能頁面；

若用戶有2個及以上的角色，但角色之間可能存在無法兼容的情況，登錄時彈框加載該用戶所有角色的列表，讓用戶自己選擇角色後，加載該角色的功能頁面。

同時提示可以在【我的】->【角色切換】進行角色的切換，并在本地緩存該角色的記錄，下次登錄時通過讀取緩存，自動加載該角色的功能頁面。

七、其他授權

這裡需要說明的是，授權不僅僅可以對角色進行功能授權，實際上還可以通過将角色與組織機構、行政區劃、标簽等緯度進行關聯授權，甚至是直接将用戶與組織機構、行政區劃、标簽等緯度進行關聯授權。

但在本文中，暫時先不考慮這種多維度的授權邏輯，隻讨論常規的功能授權。

這裡筆者隻根據自己的經驗整理了一下思路，歡迎大家積極吐槽，期待能與大家一起讨論找到更好的解決方案，謝謝各位的賞讀~

本文由 @Elaine 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自Pexels，基于 CC0 協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部