平臺級 SAAS 架構的基礎：統一身份管理系統

業內在用戶統一身份認證及授權管理領域，主要關注 4 個方面：集中賬號管理（Account）、集中認證管理（Authentication）、集中授權管理（Authorization）和集中審計管理（Audit），簡稱 4A 管理。后來發展了 IAM（Identity and Access Management，即身份識別與訪問管理）的相關技術，在云計算等領域應用廣泛。整體來說，不管是 4A 還是 IAM 還是未來可能的其他技術體系，都可以歸納為『統一身份治理』的范疇。本文基于『統一身份治理』的概念提出了統一身份管理系統（Unified Identity Management System）的設計思路。

一、統一身份管理系統（Unified Identity Management System）

統一身份管理系統（簡稱 UIMS）可以簡單理解為多租戶軟件架構的升級版，通常是整個平臺帳號和權限管控的基礎性系統，平臺下所有系統的賬戶管理、身份認證、用戶授權、權限控制等行為都必須經由該系統處理，提供帳號密碼管理、基本資料管理、角色權限管理等功能。UIMS 基于『統一身份治理』的概念，可劃分為兩級賬戶體系、基礎權限模塊和基礎信息模塊三大模塊。其中兩級賬戶體系將賬戶分為組織實體帳號和個人實體賬戶兩大類，個人實體從屬于組織實體，也可以不從屬任何組織實體，且個人實體可同時從屬于多個組織實體；基礎權限模塊將各業務系統的資源權限進行統一管理和授權；基礎信息模塊用于描述組織實體和個人實體的基本信息，如組織實體名稱、地址、法人，個人實體姓名、電話號碼、性別等基礎信息。UIMS 提供統一的 API 與各子系統連接。

從整個平臺的角度來看，UIMS 除了提供上述功能和服務，還應該滿足以下需求：

編號	需求	描述
1	軟件授權	云平臺付費授權機制，可按時間、功能、數量等進行付費授權
2	組織入駐	允許組織主動申請加入平臺
3	實名認證	個人實名認證、組織實名認證
4	資質審核	個人和組織的資質審核，如對獲得的證書或榮譽進行審核
5	組織綁定	個人賬戶綁定組織，與組織建立關聯關系
6	組織解綁	個人賬戶與組織進行解綁
7	賬戶注銷	個人賬戶注銷，并銷毀所有個人資料和檔案
8	統一登錄	即 SSO
9	統一注冊	提供統一的用戶注冊頁面

因此，從功能的角度可以將 UIMS 劃分為以下模塊：

一）功能系統設置 System Configuration系統標識管理 System Identifiers Management服務賬戶管理 Service Accounts Management賬戶實體管理 Account Entities Management組織實體管理 Organization Entities Management組織架構管理 Organization Management個體賬戶管理 Individual Accounts Management賬戶權限管理 Account Permissions Management用戶組管理 User Group Management角色管理 User Roles Management資源權限管理 Permission Resources Management權限策略組管理 Permission Group Management認證審核管理 Certification Management個人認證管理 Individual Certification Management組織認證管理 Organization Certification Management資質審核管理 Qualification Management付費授權管理 Authorization Management組織授權管理 Organization Authorization Management二）頁面統一注冊頁面 Unified Signup Page統一登錄頁面 Unified Signin Page組織入駐頁面 Organization Signup Page個人實名認證頁面 Individual Authentication Page組織實名認證頁面 Organization Authentication Page三）APIIDP（Identity Provider）相關的APIs業務相關的APIs

其中組織綁定和解綁的功能，可以放到『組織實體管理』或『個體賬戶管理』的功能中。需要注意的是，組織綁定與解綁功能，是否與業務系統關聯，下文將進行闡述。

二、兩級賬戶體系和基礎權限模塊

基于『統一身份治理』的理念，采用兩級賬戶體系（UIMS 提供接口）實現多系統融合的平臺級 SaaS。兩級賬戶體系將賬戶類別分為組織實體和個人實體兩類（詳見下文用戶分類）。個人實體可以從屬于組織實體（可以從屬于多個組織實體），也可以不從屬。個人賬戶體系和組織賬戶體系在云平臺內享有的權限是不一樣的，雖然大部分功能和服務兩個體系的實體均可獨立使用，互不干擾，但部分功能和服務有所不同。

1. 基本原則

平臺級 SaaS 模式賬戶體系應遵循以下幾個基本原則：

個人賬戶統一原則：個人賬戶一次注冊，全平臺通用，類似于全網通行證和 SSO，注冊和登錄都在 UIMS 進行。
業務權限獨立原則：每個子系統的權限體系是獨立管理的。『個人賬戶統一原則』明確了賬戶體系是統一的，但是對于每個子系統而言，每個賬戶所能使用的功能和服務，所能查看的數據權限是獨立維護的，比如 XXX 公司（組織）-研發T3組（用戶組）-張三（用戶）-研發人員（角色），在 CRM 系統中，擁有的資源權限（詳見下文），與其在 OA 系統中的所擁有的資源權限肯定是不一致的。
組織實體隔離原則：不同的組織實體之間，是相互隔離，獨立管理的。每個組織實體可以自行組織自己的組織體系、賬戶體系和權限體系。不同的組織實體資源權限也是隔離的。
從屬關系隔離原則（非強制）：個體賬戶與組織實體的從屬關系是基于單獨的業務系統存在的，『個人賬戶統一原則』明確的僅是個人賬戶的全網統一，但組織實體、從屬關系并沒有統一，并且是隔離的。比如在 CRM 系統中，張三（用戶）從屬于 XXXX 公司（組織），但在 OA 系統中，張三（用戶）默認是不從屬于任何組織的，從屬關系受到具體業務系統的影響。事實上，這個原則是非強制的，具體取決于各自的業務邏輯和業務場景。如果要簡化從屬關系的管理，那么可以不遵循此原則，即個體賬戶與組織實體的從屬關系是全平臺統一的，與業務系統無關，但這會為降低平臺的靈活性和擴展性。靈活性和復雜度之間通常要做一個取舍。

2. 權限原則

類似于 RBAC 原則，平臺的權限體系采用 OS-RBAC 的概念：

OS：O 代表 Organization 組織，S 代表 System 業務系統，即權限是受到組織實體和業務系統雙重影響的。
RBAC：基于角色的訪問控制。
OS-RBAC：組織實體-業務系統-用戶-角色-權限標識。分為兩種情況：一種是有從屬組織的個人賬戶；另一種是無從屬組織的個人賬戶，后者無組織，但同樣遵守 RBAC 的權限限定，且其權限標識體系允許組織為空。
資源標識：分為邏輯資源和實體資源。邏輯資源如菜單、頁面、表單、按鈕組、按鈕、字段等功能型資源，或人員檔案、考勤記錄、任務記錄、位置數據、積分、電子錢包等數據資源；實體資源如椅子、凳子、電腦、車輛等實物資產，另外有時候部分邏輯資源也可以歸納為實體資源，如電子照片、視頻文件、音樂文件等。
條件標識：權限的約束條件，主要有可見組織架構范圍限定、時間限定、區域限定等。例如某權限僅財務部可見，有效期至11月2號，這里『財務部』屬于可見組織架構范圍限定，『至11月2號』則是時間限定。
權限標識：用于標識賬戶實體在指定的條件下擁有訪問某項功能、查看某些數據的權限。資源標識和條件標識與權限標識關聯，權限標識與角色關聯，角色與用戶關聯。例如張三（用戶）-研發人員（角色）-擁有『研發部』所有人員檔案的增上改查權限。
業務系統標識符：受『業務權限獨立原則』的約束，與傳統的資源權限有所不同的是，所有權限標識都與具體的業務系統關聯，例如企業CRM系統就是一個業務系統，具體的權限標識與業務系統有直接的關系，例如菜單、表單、頁面、按鈕、圖片等資源。
權限策略組：權限策略組是在 OG-RBAC 基礎上設置的，為簡化權限配置的一種輔助手段，在實際應用中可以不創建策略組。策略組分為平臺級策略組和業務系統級別的策略組，兩種策略組的作用域僅限于相同組織實體內部，但對于無從屬組織的個人賬戶除外。策略組與角色類似，可以將資源權限綁定到策略組中，但不同之處是，平臺級策略組可以橫跨業務系統進行平臺級的資源權限綁定。因為賬戶體系跨越多個子系統，在遵循『業務權限獨立原則』的限定下，每個子系統都需要做一套權限配置，操作上較為繁瑣，因此充分運用策略組可以大大簡化權限配置工作。平臺可以內置多套常用的策略組，終端用戶可以直接選用策略組，也可以基于某個策略組為基礎，進行修改。值得注意的是，策略組的作用域僅限于相同組織實體內部，即策略組可以橫跨業務系統，但不能同時作用于多個組織實體。
權限交集：與 RBAC2 的靜態職責分離-角色互斥原則相反，平臺采用多角色權限并集的設計。

RBAC模型

『權限標識』示例：在企業CRM系統[1]中，在2019年3月5號以前[2]，對百度科技[3]，研發中心[4]，在廣東區域[5]的所有人事檔案[6]擁有只讀權限[7]。

[1]業務系統標識；
[2]條件標識：時間限定；
[3]組織實體標識；
[4]條件標識：可見組織架構范圍限定；
[5]條件標識：區域范圍限定；
[6]資源標識；
[7]權限類型。

3. 從屬關系梳理

為簡單起見，我們將不遵守『從屬關系隔離原則』，即用戶實體與組織實體的從屬關系與業務系統無關。系統涉及的實體類型有：

業務系統（系統標識）
服務賬戶（客戶端）
個人賬戶實體
組織賬戶實體
組織架構
用戶組（非必選項）
角色實體
權限實體
資源實體
限定條件實體
權限策略組（非必選項）

3.1 與組織實體強關聯的實體

基于『組織實體隔離原則』，這類實體類型不能脫離組織實體獨立存在。

組織架構
角色實體
權限實體
資源實體
限定條件實體

由于組織架構不能脫離組織實體單獨存在，因此當用戶實體綁定組織架構時，該用戶實體必須隸屬于該組織架構所從屬的組織實體。同理可知以下從屬關系遵從同樣的約束——即每對關系的兩個實體對象必須屬于相同的組織實體：

用戶與角色
角色與權限
資源與權限
限定條件與權限

3.2 與業務系統強關聯的實體

基于『業務系統隔離原則』，這類實體類型不能脫離業務系統獨立存在。

權限實體
資源實體
限定條件實體

4. 實體類型

基于以上各項原則，實體類型又分為以下幾種情況：

組織實體（未認證）：在組織實體的模式下，可以按照組織的管理要求，獨立設置一套組織架構、賬戶和數據權限體系，比如設置下屬企業、分公司、部門、崗位職務、角色權限，組織實體缺省分配一個管理員帳戶，擁有全部權限，由管理員初始化配置信息。
組織實體（已認證）：擁有未認證組織實體的所有權利，但已認證的實體通常擁有更多的配額更少的功能限制，此外有些特定的業務功能和業務流程，必須是實名認證的實體才能使用，比如支付和交易。
個人實體（未認證）：在個人實體的模式下，享受的權利由具體的業務系統決定，原則上個人實體作為獨立的賬戶類型，應該享有基本的功能權限和數據權限，如個人中心的各項功能等。
個人實體（已認證）：與組織實體（已認證）類似。
個人實體（未從屬于組織）：未從屬組織的個人實體賬戶，與上述個人實體類型一致。
個人實體（從屬單個組織）：從屬單個組織的個人實體賬戶，除了具備個人實體賬戶的原本權利外，還受到組織權限的約束，原本個人實體不享受的權利，可能現在可以享受，原本享受的權利，可能現在不可以享受了。
個人實體（從屬多個組織）：當個人實體賬戶從屬于多個組織時，除了個人賬戶原本擁有的權利外，所從屬的組織所帶來的權利須遵循『組織實體隔離原則』，且受到『從屬關系隔離原則』的約束，具體的權利配置由各個業務系統獨立管理。這里有兩種情況：一是在用戶登錄時，必須選擇所屬的組織機構，類似于 LOL 游戲，在登錄時須選擇所屬的區域和服務器；二是在用戶登錄后，可以自由選擇組織實體，類似于阿里云或華為云的區域選擇，在用戶未選擇所屬組織時，應當按照未從屬于組織的個人實體賬戶對待。
組織管理員：組織管理員擁有該組織內部的全部資源權限，例如可以創建個人賬戶，在個人未完成首次登錄前，可以刪除（解雇），修改，在個人完成登錄后，則權限移交給了個人；刪除（解雇）時，只是個人脫離組織，個人不再擁有組織員工的權限，在組織內的個人工作經歷仍然保留，組織清除離職員工，則這些在職經歷將不為企業可管理，但個人自己可見，不可變更。

5. 用戶分類

用戶分類

6. 組織分類

組織分類

三、基礎信息模塊

基礎信息，主要針對個人實體和組織實體，如企業工商信息、通用信息等要滿足靈活擴展的需求，實體的類型種類繁多，隨著業務場景的變化，信息結構的變化也可能比較頻繁。在技術上建議采用以下兩種方式應對：

1. EAV 數據模型

EAV 即 Entity（實體）-Attribute（屬性）-Value（值）數據模型，將傳統的 ORM 映射模型——即實體屬性與數據庫表字段一一對應的模型，變換為實體屬性與數據表的行記錄一一對應的模型。EAV 模型大大增加了數據映射和相關業務邏輯的復雜程度，但是具備高度的靈活性，能夠滿足隨時變化的信息結構，滿足動態變更的實體結構、滿足字段級權限控制、滿足字段級數據版本歷史等功能。

2. 采用松散型數據結構的數據庫方案

其中的代表便是 MongoDB：一個介于關系數據庫和非關系數據庫之間的分布式文件存儲數據庫產品，在 CAP 理論中屬于 CP 范疇，支持松散數據結構，支持復雜的混合數據類型，支持 JSON 和文檔存儲。采用此方案的優勢比較明顯，除了能夠滿足 EAV 模型所具備的大部分功能外，還大大簡化了技術復雜度，支持分布式部署，推薦采用此方案。

3. 信息分類

平臺的信息主要分為基礎信息和業務信息兩大類。基礎信息分為個人實體信息和組織實體信息，主要描述實體的基本信息、通用信息，與業務相關性不大，例如姓名、性別、身份證號碼、手機號碼、企業通用信息、企業工商信息等。業務信息由各業務系統自行管理和維護，UIMS 不涉及。

實體類別	信息類別	信息范圍	備注
個人信息	基礎信息	昵稱、性別	默認公開
個人信息	基礎信息	身份證信息、籍貫、性別、出生日期、學歷、工作履歷、電話號碼、通信地址、照片、銀行卡號	須用戶授權收集和公開
個人信息	業務信息	LBS數據	須用戶授權收集和公開
個人信息	業務信息	用戶移動終端的設備信息，包括IP地址、Mac地址、操作系統信息、設備型號、識別碼等	須用戶授權收集和公開
個人信息	業務信息	用戶的行為信息，包括操作記錄，cookies，通過平臺編輯或傳送的文字、圖片、語音或視頻信息等	須用戶授權收集和公開
個人信息	業務信息	用戶喜好、特長、手工標簽、自動標簽、社交互動信息等	須用戶授權收集和公開
組織信息	基礎信息	組織工商信息：名稱、法人、營業范圍、注冊日期、注冊資本、通信地址、工商注冊號、公司類型、納稅人識別號	默認公開，自動審核
組織信息	基礎信息	組織介紹、品牌介紹、微信公眾號、企業官網、對外聯絡電話、客服電話	默認公開，須人工審核
組織信息	基礎信息	企業資質、股權結構、對外投資、工商登記變更記錄、企業年報、公司發展歷程、行政許可	須組織授權收集和公開
組織信息	基礎信息	核心團隊和成員、融資歷程、核心產品、公司規模、知識產權	須組織授權收集和公開
組織信息	基礎信息	組織架構、組織成員檔案、司法風險、法律訴訟	須組織授權收集和公開

所有與信息收集、儲存、處理及數據安全有關的書面政策，應當出具《隱私政策》并進行聲明。部分組織信息由于可在網上公開查到，且是法定必須公布的信息，因此可以默認公開。

四、其他功能

一）軟件授權

基于兩級賬戶體系，建立云平臺付費授權機制，針對用戶賬戶和組織賬戶進行獨立授權。根據產品的商業策略，可執行靈活的付費模式：

時效限制：年付、季付、月付，不同時效費用不同。
功能限制：授權不同的功能，費用不同。
數量限制：最大組織數量限制、最大用戶數量限制，不同的數量費用不同。

二）組織入駐

UIMS 應提供一個組織實體注冊登記的流程，允許組織主動提交基本信息，開戶入駐平臺。此外，應提供在管理后臺手工錄入組織開戶的功能。

三）實名認證

分為個人賬戶實名認證和組織賬戶實名認證，盡量通過技術手段自動執行實名認證的審核過程，減少甚至取消人工干預。UIMS 應提供實名認證的功能和流程。

四）資質審核

資質審核分為兩部分：一是部分實體實名認證過程中的人工核查；二是對實體提交的額外資質進行技術或人工審核。

五）組織綁定

基于『從屬關系隔離原則』，個人賬戶應在具體的業務系統中綁定組織賬戶，綁定過程分為兩種類型：一是由組織管理員手工創建的從屬個人賬戶，另一個是個人賬戶申請加入某個組織。業務系統應該提供此功能和流程。例如，個人注冊帳號后，可主動登記綁定組織，對已注冊登記的組織則要該組織管理員審核，未在系統中注冊登記的組織，則始終處于待審核狀態。