業內在用戶統一身份認證及授權管理領域，主要關注 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
認證審覈管理 Authentication Management
個人認證管理 Individual Authentication Management
組織認證管理 Organization Authentication Management
資質審覈管理 Qualification Management
付費授權管理 Authorization Management
組織授權管理 Organization Authorization Management
二）頁面
統一註冊頁面 Unified Signup Page
統一登錄頁面 Unified Signin Page
組織入駐頁面 Organization Signup Page
個人實名認證頁面 Individual Authentication Page
組織實名認證頁面 Organization Authentication Page
三）API
鑑權相關的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 的靜態職責分離-角色互斥原則相反，平臺採用多角色權限並集的設計。
『權限標識』示例：在企業CRM系統[1]中，在2019年3月5號以前[2]，對百度科技[3]，研發中心[4]，在廣東區域[5]的所有人事檔案[6]擁有隻讀權限[7]。
- [1]業務系統標識；
- [2]條件標識：時間限定；
- [3]組織實體標識；
- [4]條件標識：可見組織架構範圍限定；
- [5]條件標識：區域範圍限定；
- [6]資源標識；
- [7]權限類型。
3. 從屬關係梳理
一）受業務系統影響的從屬關係有
1. 用戶實體與組織實體的從屬關係
2. 用戶實體與組織架構的從屬關係
3. 用戶實體與用戶組的從屬關係
4. 用戶實體與角色的從屬關係
5. 權限（permissions）與組織實體的從屬關係
6. 資源（resources）與組織實體的從屬關係
二）不受業務系統影響的從屬關係有
- [x] 1. 組織架構與組織實體的從屬關係
2. 用戶組與組織實體的從屬關係
3. 角色與組織實體的從屬關係
業務系統（系統標識）
服務賬戶（客戶端）
個人賬戶實體
組織賬戶實體
組織架構
用戶組
角色實體
權限實體
資源實體
限定條件實體
權限策略組
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 應提供實名認證的功能和流程。
四）資質審覈
資質審覈分爲兩部分：一是部分實體實名認證過程中的人工覈查；二是對實體提交的額外資質進行技術或人工審覈。
五）組織綁定
基於『從屬關係隔離原則』，個人賬戶應在具體的業務系統中綁定組織賬戶，綁定過程分爲兩種類型：一是由組織管理員手工創建的從屬個人賬戶，另一個是個人賬戶申請加入某個組織。業務系統應該提供此功能和流程。例如，個人註冊帳號後，可主動登記綁定組織，對已註冊登記的組織則要該組織管理員審覈，未在系統中註冊登記的組織，則始終處於待審覈狀態。
六）組織解綁
允許個人賬戶解除與組織之間的從屬關係。解綁分爲兩種情況：一是個人賬戶主動解除關係，二是組織管理員解綁、解僱或清除僱員（個人賬戶）。其中第一種個人解綁的，應當由組織進行審覈批准，個人申請解除綁定關係，組織進行審覈，但是是否需要審覈，應交由具體的業務系統自行決定。
七）間接僱傭（從屬）關係
僱傭（從屬）關係分爲直接僱傭與間接僱傭關係。例如保安員在某保安公司入職（直接僱傭），在某物業作保安（間接僱傭）。考慮兩種辦法標識間接僱傭關係：
- 增加服務單位（項目點、物業社區）的實體概念
- 利用組織內部的組織機構體系，將間接僱傭單位作爲當前組織的分支機構進行處理。
八）賬戶註銷
分爲個人賬戶的註銷和組織賬戶的註銷。UIMS 應提供相應的頁面完成賬戶註銷的操作。
九）私有化部署
原則上拒絕私有化部署，但對於特定的客戶，考慮私有化部署。私有化部署須考慮版本升級問題，在軟件架構設計時，儘量遵循業務系統和技術系統分離的原則，並抽離公共模塊，最大限度爲私有部署的版本提供升級服務。
五、總結
總體來說，統一身份管理系統要做的事情有這麼幾件：
- 定義實體
- 業務系統實體
- 服務賬戶實體（客戶端）
- 組織實體
- 組織架構
- 個人實體
- 角色實體
- 權限標識
- 資源標識
- 條件標識
- 處理上述各實體之間的關係，並提供數據結構
- 提供鑑權 APIs 和業務 APIs
- 提供其他功能：統一註冊功能（頁面和流程）、統一登錄功能、軟件授權
、組織入駐、組織綁定/解綁、資質審查。