文章是基于業務中臺多租戶權限管理設計的整體方案，筆者梳理了后臺系統權限管理設計的一般方法、需要解決的問題以及總結了具體的設計方案。

一、后臺系統中權限管理設計的一般方法

在設計后臺系統（如：CRM、EPR、EHR、電商管理后臺等）時，權限管理是必不可少的功能，絕大部分的后臺系統都是處理企業業務流程的，會涉及到多個部門的協同合作，必然需要對每個能夠使用系統的用戶進行權限管理。

在一般的單體應用的后臺中權限管理的大體模式如下：

整體的業務邏輯如下：

1. 系統中的菜單、頁面、按鈕、字段以及運行時產生的數據都需要注冊成為系統資源；
2. 系統資源打包組合成為角色；
3. 角色可以關聯用戶，也就完成了資源授權給用戶的處理
4. 角色可以關聯用戶組，而用戶組是多個用戶組合而成的一個集合，用戶能夠繼承用戶組關聯的角色

而在系統運行時，任何一個用戶在使用系統資源時，都需要進行授權校驗，也就是看這個用戶關聯的所有的角色囊括的資源是否包涵當前要訪問的資源，如此就完成了用戶權限管理的控制。

你沒有看錯，所有的單體應用的權限管理的實現邏輯都是如此。

但在基于業務中臺的基礎之上去做權限管理的設計我們需要額外引入更多的概念（租戶、應用實例等）以完成業務邏輯。

二、基于業務中臺的多租戶權限設計需要解決的問題

所有中臺建設的目的都是為了業務快速且低成本創新，絕大部分的企業基于中臺都會開發大量的業務應用，一般基于業務中臺的架構如下圖：

從圖中可以看到，在中臺之上有針對各個業務開展的各種應用，而筆者所在的企業是一家中臺標準產品的廠商（即把中臺作為基礎設施的SaaS廠商），更是加入了多租戶的機制以滿足不同客戶對應個性化的需求。

在基于中臺的多租戶、多應用的場景下，我們做權限管理的設計面臨如下主要問題：

1. 在出廠時需要提供特殊的初始化權限管理流程；
2. 對于購買SaaS產品的客戶而言，權限需要集中進行管理，以減少運營人員的工作內容；
3. 對于不同的角色/場景有不同的權限管理的需求。

三、具體的設計方案闡述

在解決以上問題之前我首先介紹下我們公司的整體產品架構：

業務中臺是我們所有應用的基礎設施，我們能夠通過MPC 配置各個應用所需要的業務能力，把業務能力組合起來就能形成一個應用，如此我們實現了業務中臺的能力復用以及快速支撐業務創新。

在這個業務模式中，應用均是通過配置在進行一定的前端頁面開發形成，我們可以為每個租戶生產其所需要的應用實例，租戶下的數據是隔離的。

在客戶購買我們整個標準產品后（包括業務中臺、MPC、BOC以及預置應用），首先我們在MPC中預置了一個root賬戶，通過該賬戶我能夠創建租戶，并為租戶實例化應用，在實例化應用的同時，為該租戶生成在該應用實例下的租戶管理員。

租戶管理員能夠進入BOC進行全局的權限管理，例如：他能在該租戶下創建用戶，并設置該用戶能夠登錄的應用；他能為租戶下的任一應用實例創建角色，并把該角色分配租戶下的用戶。

租戶管理員管理權限的模式如下：

整體業務邏輯：

1. 系統初始化時，需要生成root賬號，該賬號由系統預置所有資源權限
2. root賬號能夠創建租戶，并為租戶實例化應用
3. 實例化應用的時候需要為租戶生成租戶管理員并賦予租戶管理員該應用實例的管理員權限（管理員角色為應用預置）

以上是解決出廠初始化時的特殊的權限管理處理邏輯。

租戶管理員能夠在全局管理（BOC）中管理租戶下的用戶信息，并能夠為用戶關聯應用及應用中的角色；

原型示意圖

租戶管理員能夠在全局管理中管理每一個應用實例中角色；

具有應用實例權限的用戶能夠進入應用，并創建該應用實例下的用戶、角色。

四、總結

以上就是我在基于業務中臺多租戶下權限管理設計的整體方案，租戶是在SaaS模式下隔離數據使用，在數據層面有自己的獨立空間；

應用實例指的是租戶數據空間中運行的應用；用戶是使用系統的直接對象，其能夠使用資源是由其關聯的角色決定；資源指的是系統中的菜單、頁面、按鈕、字段以及運行時產生的數據。

理清這些概念后即使是再復雜的系統我們進行權限管理設計也是不在話下。

對應上內容如有異議，歡迎大家隨時與我探討。

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

題圖來自 unsplash，基于 CC0 協議