UIMS即統(tǒng)一身份管理系統(tǒng)，可以認為是多租戶架構的升級版，通常是整個平臺賬號和權限管控的基礎性系統(tǒng)，可劃分為兩級賬戶體系、基礎權限模塊和基礎信息模塊三大模塊。本文從這三個方面對UIMS進行了分析闡述，一起來看一下吧。

一、概述

統(tǒng)一身份管理系統(tǒng)（簡稱UIMS）主要關注4個方面，簡稱4A管理：

1. 集中賬號管理（Account）
2. 集中認證管理（Authentication）
3. 集中授權管理（Authorization）
4. 集中審計管理（Audit）

可以認為是多租戶架構的升級版，通常是整個平臺帳號和權限管控的基礎性系統(tǒng)，平臺下所有系統(tǒng)的賬戶管理、身份認證、用戶授權、權限控制等行為都必須經由該系統(tǒng)處理，提供帳號密碼管理、基本資料管理、角色權限管理等功能。

UIMS 基于『統(tǒng)一身份治理』的概念，可劃分為兩級賬戶體系、基礎權限模塊和基礎信息模塊三大模塊。

其中兩級賬戶體系將賬戶分為組織實體帳號和個人實體賬戶兩大類，個人實體從屬于組織實體，也可以不從屬任何組織實體，且個人實體可同時從屬于多個組織實體；基礎權限模塊將各業(yè)務系統(tǒng)的資源權限進行統(tǒng)一管理和授權；基礎信息模塊用于描述組織實體和個人實體的基本信息，如組織實體名稱、地址、法人，個人實體姓名、電話號碼、性別等基礎信息。UIMS 提供統(tǒng)一的 API 與各子系統(tǒng)連接。

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

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

1. 功能

1. 系統(tǒng)設置System Configuration

2. 系統(tǒng)標識管理System Identifiers Management

3. 服務賬戶管理Service Accounts Management

4. 賬戶實體管理Account Entities Management

5. 組織實體管理Organization Entities Management

6. 組織架構管理Organization Management

7. 個體賬戶管理Individual Accounts Management

8. 賬戶權限管理Account Permissions Management

9. 用戶組管理User Group Management

10. 角色管理User Roles Management

11. 資源權限管理Permission Resources Management

12. 權限策略組管理Permission Group Management

13. 認證審核管理Authentication Management

14. 個人認證管理Individual Authentication Management

15. 組織認證管理Organization Authentication Management

16. 資質審核管理Qualification Management

17. 付費授權管理Authorization Management

18. 組織授權管理Organization Authorization Management

2. 頁面

1. 統(tǒng)一注冊頁面Unified Signup Page

2. 統(tǒng)一登錄頁面Unified Signin Page

3. 組織入駐頁面Organization Signup Page

4. 個人實名認證頁面Individual Authentication Page

5. 組織實名認證頁面Organization Authentication Page

3. API

1. 鑒權相關的API

2. 業(yè)務相關的API

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

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

基于『統(tǒng)一身份治理』的理念，采用兩級賬戶體系（UIMS 提供接口）實現(xiàn)多系統(tǒng)融合的平臺級 SAAS。兩級賬戶體系將賬戶類別分為組織實體和個人實體兩類（詳見下文用戶分類）。

個人實體可以從屬于組織實體（可以從屬于多個組織實體），也可以不從屬。個人賬戶體系和組織賬戶體系在云平臺內享有的權限是不一樣的，雖然大部分功能和服務兩個體系的實體均可獨立使用，互不干擾，但部分功能和服務有所不同。

1. 原則

1）基本原則

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

①個人賬戶統(tǒng)一原則

個人賬戶一次注冊，全平臺通用，類似于全網通行證和SSO，注冊和登錄都在 UIMS 進行。

②業(yè)務權限獨立原則

每個子系統(tǒng)的權限體系是獨立管理的?！簜€人賬戶統(tǒng)一原則』明確了賬戶體系是統(tǒng)一的，但是對于每個子系統(tǒng)而言，每個賬戶所能使用的功能和服務，所能查看的數(shù)據(jù)權限是獨立維護的，比如XXX 公司（組織）—研發(fā)T3組（組織架構）—張三（個人）—研發(fā)人員（角色），在 CRM 系統(tǒng)中，擁有的資源權限（詳見下文），與其在 OA 系統(tǒng)中的所擁有的資源權限肯定是不一致的。

③組織實體隔離原則

不同的組織實體之間，是相互隔離，獨立管理的。每個組織實體可以自行組織自己的組織架構、賬戶體系和權限體系。不同的組織實體資源權限也是隔離的。

④從屬關系隔離原則

個體賬戶與組織實體的從屬關系是基于單獨的業(yè)務系統(tǒng)存在的，『個人賬戶統(tǒng)一原則』明確的僅是個人賬戶的全網統(tǒng)一，但組織實體、從屬關系并沒有統(tǒng)一，并且是隔離的。比如在CRM 系統(tǒng)中，張三（用戶）從屬于 XXXX 公司（組織），但在 OA 系統(tǒng)中，張三（用戶）默認是不從屬于任何組織的，從屬關系受到具體業(yè)務系統(tǒng)的影響。

事實上，這個原則是非強制的，具體取決于各自的業(yè)務邏輯和業(yè)務場景。如果要簡化從屬關系的管理，那么可以不遵循此原則，即個體賬戶與組織實體的從屬關系是全平臺統(tǒng)一的，與業(yè)務系統(tǒng)無關，但這會為降低平臺的靈活性和擴展性。靈活性和復雜度之間通常要做一個取舍。

2）權限原則

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

1. OS：O 代表 Organization 組織，S 代表 System 業(yè)務系統(tǒng)，即權限是受到組織實體和業(yè)務系統(tǒng)雙重影響的。

2. RBAC：基于角色的訪問控制。

3. OS-RBAC：組織實體-業(yè)務系統(tǒng)-用戶-角色-權限標識。分為兩種情況：一種是有從屬組織的個人賬戶；另一種是無從屬組織的個人賬戶，后者無組織，但同樣遵守 RBAC 的權限限定，且其權限標識體系允許組織為空。

4. 資源標識：分為邏輯資源和實體資源。邏輯資源包括功能資源和數(shù)據(jù)資源，如菜單、頁面、表單、按鈕組、按鈕、字段等功能型資源，或人員檔案、考勤記錄、任務記錄、位置數(shù)據(jù)、積分、電子錢包等數(shù)據(jù)資源；實體資源如椅子、凳子、電腦、車輛等實物資產，另外有時候部分邏輯資源也可以歸納為實體資源，如電子照片、視頻文件、音樂文件等。

5. 條件標識：權限的約束條件，主要有可見組織架構范圍限定、時間限定、區(qū)域限定等。例如某權限僅財務部可見，有效期至11月2號，這里『財務部』屬于可見組織架構范圍限定，『至11月2號』則是時間限定。

6. 權限標識：用于標識賬戶實體在指定的條件下?lián)碛性L問某項功能、查看某些數(shù)據(jù)的權限。資源標識和條件標識與權限標識關聯(lián)，權限標識與角色關聯(lián)，角色與用戶關聯(lián)。例如張三（用戶）-研發(fā)人員（角色）-擁有『研發(fā)部』所有人員檔案的增上改查權限。

7. 業(yè)務系統(tǒng)標識符：受『業(yè)務權限獨立原則』的約束，與傳統(tǒng)的資源權限有所不同的是，所有權限標識都與具體的業(yè)務系統(tǒng)關聯(lián)，例如企業(yè)CRM系統(tǒng)就是一個業(yè)務系統(tǒng)，具體的權限標識與業(yè)務系統(tǒng)有直接的關系，例如菜單、表單、頁面、按鈕、圖片等資源。

8. 權限策略組：權限策略組是在OS-RBAC 基礎上設置的，為簡化權限配置的一種輔助手段，在實際應用中可以不創(chuàng)建策略組。策略組分為平臺級策略組和業(yè)務系統(tǒng)級別的策略組，兩種策略組的作用域僅限于相同組織實體內部，但對于無從屬組織的個人賬戶除外。策略組與角色類似，可以將資源權限綁定到策略組中，但不同之處是，平臺級策略組可以橫跨業(yè)務系統(tǒng)進行平臺級的資源權限綁定。因為賬戶體系跨越多個子系統(tǒng)，在遵循『業(yè)務權限獨立原則』的限定下，每個子系統(tǒng)都需要做一套權限配置，操作上較為繁瑣，因此充分運用策略組可以大大簡化權限配置工作。平臺可以內置多套常用的策略組，終端用戶可以直接選用策略組，也可以基于某個策略組為基礎，進行修改。值得注意的是，策略組的作用域僅限于相同組織實體內部，即策略組可以橫跨業(yè)務系統(tǒng)，但不能同時作用于多個組織實體。

9. 權限交集：與RBAC2 的靜態(tài)職責分離-角色互斥原則相反，平臺采用多角色權限并集的設計。

表1RBAC模型

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

[1]業(yè)務系統(tǒng)標識；

[2]條件標識：時間限定；

[3]組織實體標識；

[4]條件標識：可見組織架構范圍限定；

[5]條件標識：區(qū)域范圍限定；

[6]資源標識；

[7]權限類型。

2. 從屬關系

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

1．業(yè)務系統(tǒng)（系統(tǒng)標識）

2．服務賬戶（客戶端）

3．個人賬戶實體

4．組織賬戶實體

5．組織架構

6．用戶組（非必選項）

7．角色實體

8．權限實體

9．資源實體

10．限定條件實體

11．權限策略組（非必選項）

1）與組織實體強關聯(lián)的實體

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

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

2）與業(yè)務系統(tǒng)強關聯(lián)的實體

基于『業(yè)務系統(tǒng)隔離原則』，這類實體類型不能脫離業(yè)務系統(tǒng)獨立存在。

3. 實體類型

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

1）組織實體（未認證）

在組織實體的模式下，可以按照組織的管理要求，獨立設置一套組織架構、賬戶和數(shù)據(jù)權限體系，比如設置下屬企業(yè)、分公司、部門、崗位職務、角色權限，組織實體缺省分配一個管理員帳戶，擁有全部權限，由管理員初始化配置信息。

2）組織實體（已認證）

擁有未認證組織實體的所有權利，但已認證的實體通常擁有更多的配額更少的功能限制，此外有些特定的業(yè)務功能和業(yè)務流程，必須是實名認證的實體才能使用，比如支付和交易。

3）個人實體（未認證）

在個人實體的模式下，享受的權利由具體的業(yè)務系統(tǒng)決定，原則上個人實體作為獨立的賬戶類型，應該享有基本的功能權限和數(shù)據(jù)權限，如個人中心的各項功能等。

4）個人實體（已認證）

與組織實體（已認證）類似。

5）個人實體（未從屬于組織）

未從屬組織的個人實體賬戶，與上述個人實體類型一致。

6）個人實體（從屬單個組織）

從屬單個組織的個人實體賬戶，除了具備個人實體賬戶的原本權利外，還受到組織權限的約束，原本個人實體不享受的權利，可能現(xiàn)在可以享受，原本享受的權利，可能現(xiàn)在不可以享受了。

7）個人實體（從屬多個組織）

當個人實體賬戶從屬于多個組織時，除了個人賬戶原本擁有的權利外，所從屬的組織所帶來的權利須遵循『組織實體隔離原則』，且受到『從屬關系隔離原則』的約束，具體的權利配置由各個業(yè)務系統(tǒng)獨立管理。

這里有兩種情況：一是在用戶登錄時，必須選擇所屬的組織機構，類似于LOL 游戲，在登錄時須選擇所屬的區(qū)域和服務器；二是在用戶登錄后，可以***選擇組織實體，類似于阿里云或華為云的區(qū)域選擇，在用戶未選擇所屬組織時，應當按照未從屬于組織的個人實體賬戶對待。

8）組織管理員

組織管理員擁有該組織內部的全部資源權限，例如可以創(chuàng)建個人賬戶，在個人未完成首次登錄前，可以刪除（解雇），修改，在個人完成登錄后，則權限移交給了個人；刪除（解雇）時，只是個人脫離組織，個人不再擁有組織員工的權限，在組織內的個人工作經歷仍然保留，組織清除離職員工，則這些在職經歷將不為企業(yè)可管理，但個人自己可見，不可變更。

4. 用戶分類

表2用戶分類

5. 組織分類

表3組織分類

三、基礎信息模塊

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

1. EAV 數(shù)據(jù)模型

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

2. 采用松散型數(shù)據(jù)結構的數(shù)據(jù)庫方案

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

3. 信息分類

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

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

四、其他功能模塊

1. 軟件授權

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

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

2. 組織入駐

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

3. 實名認證

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

4. 資質審核

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

5. 組織綁定

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

6. 組織解綁

允許個人賬戶解除與組織之間的從屬關系。解綁分為兩種情況：一是個人賬戶主動解除關系，二是組織管理員解綁、解雇或清除雇員（個人賬戶）。

其中第一種個人解綁的，應當由組織進行審核批準，個人申請解除綁定關系，組織進行審核，但是是否需要審核，應交由具體的業(yè)務系統(tǒng)自行決定。

7. 間接雇傭（從屬）關系

雇傭（從屬）關系分為直接雇傭與間接雇傭關系。例如保安員在某保安公司入職（直接雇傭），在某物業(yè)作保安（間接雇傭）?？紤]兩種辦法標識間接雇傭關系。

8. 增加服務單位（項目點、物業(yè)社區(qū)）的實體概念

利用組織內部的組織機構體系，將間接雇傭單位作為當前組織的分支機構進行處理。

9. 賬戶注銷

分為個人賬戶的注銷和組織賬戶的注銷。UIMS 應提供相應的頁面完成賬戶注銷的操作。

10. 私有化部署

原則上拒絕私有化部署，但對于特定的客戶，考慮私有化部署。私有化部署須考慮版本升級問題，在軟件架構設計時，盡量遵循業(yè)務系統(tǒng)和技術系統(tǒng)分離的原則，并抽離公共模塊，最大限度為私有部署的版本提供升級服務。

五、總結

總體來說，統(tǒng)一身份管理系統(tǒng)要做的事情有這么幾件：

1. 定義實體

2. 業(yè)務系統(tǒng)實體

3. 服務賬戶實體（客戶端）

4. 組織實體

5. 組織架構

6. 個人實體

7. 角色實體

8. 權限標識

9. 資源標識

10. 條件標識

11. 處理上述各實體之間的關系，并提供數(shù)據(jù)結構

12. 提供鑒權API和業(yè)務 API

13. 提供其他功能：統(tǒng)一注冊功能（頁面和流程）、統(tǒng)一登錄功能、軟件授權、組織入駐、組織綁定/解綁、資質審查。

本文由@劉同學 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。