UIMS即統一身份管理系統，可以認為是多租戶架構的更新版，通常是整個平台賬号和權限管控的基礎性系統，可劃分為兩級賬戶體系、基礎權限子產品和基礎資訊子產品三大子產品。本文從這三個方面對UIMS進行了分析闡述，一起來看一下吧。
一、概述
統一身份管理系統（簡稱UIMS）主要關注4個方面，簡稱4A管理：
- 集中賬号管理（Account）
- 集中認證管理（Authentication）
- 集中授權管理（Authorization）
- 集中審計管理（Audit）
可以認為是多租戶架構的更新版，通常是整個平台帳号和權限管控的基礎性系統，平台下所有系統的賬戶管理、身份認證、使用者授權、權限控制等行為都必須經由該系統處理，提供帳号密碼管理、基本資料管理、角色權限管理等功能。
UIMS 基于『統一身份治理』的概念，可劃分為兩級賬戶體系、基礎權限子產品和基礎資訊子產品三大子產品。
其中兩級賬戶體系将賬戶分為組織實體帳号和個人實體賬戶兩大類，個人實體從屬于組織實體，也可以不從屬任何組織實體，且個人實體可同時從屬于多個組織實體；基礎權限子產品将各業務系統的資源權限進行統一管理和授權；基礎資訊子產品用于描述組織實體和個人實體的基本資訊，如組織實體名稱、位址、法人，個人實體姓名、電話号碼、性别等基礎資訊。UIMS 提供統一的 API 與各子系統連接配接。
從整個平台的角度來看，UIMS 除了提供上述功能和服務，還應該滿足以下需求：
是以，從功能的角度可以将UIMS 劃分為以下子產品：
1. 功能
1. 系統設定System Configuration
2. 系統辨別管理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. 統一注冊頁面Unified Signup Page
2. 統一登入頁面Unified Signin Page
3. 組織入駐頁面Organization Signup Page
4. 個人實名認證頁面Individual Authentication Page
5. 組織實名認證頁面Organization Authentication Page
3. API
1. 鑒權相關的API
2. 業務相關的API
其中組織綁定和解綁的功能，可以放到『組織實體管理』或『個體賬戶管理』的功能中。需要注意的是，組織綁定與解綁功能，是否與業務系統關聯，下文将進行闡述。
二、兩級賬戶體系和基礎權限子產品
基于『統一身份治理』的理念，采用兩級賬戶體系（UIMS 提供接口）實作多系統融合的平台級 SAAS。兩級賬戶體系将賬戶類别分為組織實體和個人實體兩類（詳見下文使用者分類）。
個人實體可以從屬于組織實體（可以從屬于多個組織實體），也可以不從屬。個人賬戶體系群組織賬戶體系在雲平台内享有的權限是不一樣的，雖然大部分功能和服務兩個體系的實體均可獨立使用，互不幹擾，但部分功能和服務有所不同。
1. 原則
1）基本原則
平台級SAAS 模式賬戶體系應遵循以下幾個基本原則：
①個人賬戶統一原則
個人賬戶一次注冊，全平台通用，類似于全網通行證和SSO，注冊和登入都在 UIMS 進行。
②業務權限獨立原則
每個子系統的權限體系是獨立管理的。『個人賬戶統一原則』明确了賬戶體系是統一的，但是對于每個子系統而言，每個賬戶所能使用的功能和服務，所能檢視的資料權限是獨立維護的，比如XXX 公司（組織）—研發T3組（組織架構）—張三（個人）—研發人員（角色），在 CRM 系統中，擁有的資源權限（詳見下文），與其在 OA 系統中的所擁有的資源權限肯定是不一緻的。
③組織實體隔離原則
不同的組織實體之間，是互相隔離，獨立管理的。每個組織實體可以自行組織自己的組織架構、賬戶體系和權限體系。不同的組織實體資源權限也是隔離的。
④從屬關系隔離原則
個體賬戶與組織實體的從屬關系是基于單獨的業務系統存在的，『個人賬戶統一原則』明确的僅是個人賬戶的全網統一，但組織實體、從屬關系并沒有統一，并且是隔離的。比如在CRM 系統中，張三（使用者）從屬于 XXXX 公司（組織），但在 OA 系統中，張三（使用者）預設是不從屬于任何組織的，從屬關系受到具體業務系統的影響。
事實上，這個原則是非強制的，具體取決于各自的業務邏輯和業務場景。如果要簡化從屬關系的管理，那麼可以不遵循此原則，即個體賬戶與組織實體的從屬關系是全平台統一的，與業務系統無關，但這會為降低平台的靈活性和擴充性。靈活性和複雜度之間通常要做一個取舍。
2）權限原則
類似于 RBAC 原則，平台的權限體系采用 OS-RBAC 的概念：
1. OS：O 代表 Organization 組織，S 代表 System 業務系統，即權限是受到組織實體和業務系統雙重影響的。
2. RBAC：基于角色的通路控制。
3. OS-RBAC：組織實體-業務系統-使用者-角色-權限辨別。分為兩種情況：一種是有從屬組織的個人賬戶；另一種是無從屬組織的個人賬戶，後者無組織，但同樣遵守 RBAC 的權限限定，且其權限辨別體系允許組織為空。
4. 資源辨別：分為邏輯資源和實體資源。邏輯資源包括功能資源和資料資源，如菜單、頁面、表單、按鈕組、按鈕、字段等功能型資源，或人員檔案、考勤記錄、任務記錄、位置資料、積分、電子錢包等資料資源；實體資源如椅子、凳子、電腦、車輛等實物資産，另外有時候部分邏輯資源也可以歸納為實體資源，如電子照片、視訊檔案、音樂檔案等。
5. 條件辨別：權限的限制條件，主要有可見組織架構範圍限定、時間限定、區域限定等。例如某權限僅财務部可見，有效期至11月2号，這裡『财務部』屬于可見組織架構範圍限定，『至11月2号』則是時間限定。
6. 權限辨別：用于辨別賬戶實體在指定的條件下擁有通路某項功能、檢視某些資料的權限。資源辨別和條件辨別與權限辨別關聯，權限辨別與角色關聯，角色與使用者關聯。例如張三（使用者）-研發人員（角色）-擁有『研發部』所有人員檔案的增上改查權限。
7. 業務系統辨別符：受『業務權限獨立原則』的限制，與傳統的資源權限有所不同的是，所有權限辨別都與具體的業務系統關聯，例如企業CRM系統就是一個業務系統，具體的權限辨別與業務系統有直接的關系，例如菜單、表單、頁面、按鈕、圖檔等資源。
8. 權限政策組：權限政策組是在OS-RBAC 基礎上設定的，為簡化權限配置的一種輔助手段，在實際應用中可以不建立政策組。政策組分為平台級政策組和業務系統級别的政策組，兩種政策組的作用域僅限于相同組織實體内部，但對于無從屬組織的個人賬戶除外。政策組與角色類似，可以将資源權限綁定到政策組中，但不同之處是，平台級政策組可以橫跨業務系統進行平台級的資源權限綁定。因為賬戶體系跨越多個子系統，在遵循『業務權限獨立原則』的限定下，每個子系統都需要做一套權限配置，操作上較為繁瑣，是以充分運用政策組可以大大簡化權限配置工作。平台可以内置多套常用的政策組，終端使用者可以直接選用政策組，也可以基于某個政策組為基礎，進行修改。值得注意的是，政策組的作用域僅限于相同組織實體内部，即政策組可以橫跨業務系統，但不能同時作用于多個組織實體。
9. 權限交集：與RBAC2 的靜态職責分離-角色互斥原則相反，平台采用多角色權限并集的設計。
表1RBAC模型
『權限辨別』示例：在企業CRM系統[1]中，在2019年3月5号以前[2]，對百度科技[3]，研發中心[4]，在廣東區域[5]的所有人事檔案[6]擁有隻讀權限[7]。
[1]業務系統辨別；
[2]條件辨別：時間限定；
[3]組織實體辨別；
[4]條件辨別：可見組織架構範圍限定；
[5]條件辨別：區域範圍限定；
[6]資源辨別；
[7]權限類型。
2. 從屬關系
為簡單起見，我們将不遵守『從屬關系隔離原則』，即使用者實體與組織實體的從屬關系與業務系統無關。系統涉及的實體類型有：
1．業務系統（系統辨別）
2．服務賬戶（用戶端）
3．個人賬戶實體
4．組織賬戶實體
5．組織架構
6．使用者組（非必選項）
7．角色實體
8．權限實體
9．資源實體
10．限定條件實體
11．權限政策組（非必選項）
1）與組織實體強關聯的實體
基于『組織實體隔離原則』，這類實體類型不能脫離組織實體獨立存在。
由于組織架構不能脫離組織實體單獨存在，是以當使用者實體綁定組織架構時，該使用者實體必須隸屬于該組織架構所從屬的組織實體。同理可知以下從屬關系遵從同樣的限制——即每對關系的兩個實體對象必須屬于相同的組織實體：
2）與業務系統強關聯的實體
基于『業務系統隔離原則』，這類實體類型不能脫離業務系統獨立存在。
3. 實體類型
基于以上各項原則，實體類型又分為以下幾種情況：
1）組織實體（未認證）
在組織實體的模式下，可以按照組織的管理要求，獨立設定一套組織架構、賬戶和資料權限體系，比如設定下屬企業、分公司、部門、崗位職務、角色權限，組織實體預設配置設定一個管理者帳戶，擁有全部權限，由管理者初始化配置資訊。
2）組織實體（已認證）
擁有未認證組織實體的所有權利，但已認證的實體通常擁有更多的配額更少的功能限制，此外有些特定的業務功能和業務流程，必須是實名認證的實體才能使用，比如支付和交易。
3）個人實體（未認證）
在個人實體的模式下，享受的權利由具體的業務系統決定，原則上個人實體作為獨立的賬戶類型，應該享有基本的功能權限和資料權限，如個人中心的各項功能等。
4）個人實體（已認證）
與組織實體（已認證）類似。
5）個人實體（未從屬于組織）
未從屬組織的個人實體賬戶，與上述個人實體類型一緻。
6）個人實體（從屬單個組織）
從屬單個組織的個人實體賬戶，除了具備個人實體賬戶的原本權利外，還受到組織權限的限制，原本個人實體不享受的權利，可能現在可以享受，原本享受的權利，可能現在不可以享受了。
7）個人實體（從屬多個組織）
當個人實體賬戶從屬于多個組織時，除了個人賬戶原本擁有的權利外，所從屬的組織所帶來的權利須遵循『組織實體隔離原則』，且受到『從屬關系隔離原則』的限制，具體的權利配置由各個業務系統獨立管理。
這裡有兩種情況：一是在使用者登入時，必須選擇所屬的組織機構，類似于LOL 遊戲，在登入時須選擇所屬的區域和伺服器；二是在使用者登入後，可以***選擇組織實體，類似于阿裡雲或華為雲的區域選擇，在使用者未選擇所屬組織時，應當按照未從屬于組織的個人實體賬戶對待。
8）組織管理者
組織管理者擁有該組織内部的全部資源權限，例如可以建立個人賬戶，在個人未完成首次登入前，可以删除（解雇），修改，在個人完成登入後，則權限移交給了個人；删除（解雇）時，隻是個人脫離組織，個人不再擁有組織員工的權限，在組織内的個人工作經曆仍然保留，組織清除離職員工，則這些在職經曆将不為企業可管理，但個人自己可見，不可變更。
4. 使用者分類
表2使用者分類
5. 組織分類
表3組織分類
三、基礎資訊子產品
基礎資訊，主要針對個人實體群組織實體，如企業工商資訊、通用資訊等要滿足靈活擴充的需求，實體的類型種類繁多，随着業務場景的變化，資訊結構的變化也可能比較頻繁。在技術上建議采用以下兩種方式應對：
1. EAV 資料模型
EAV 即 Entity（實體）-Attribute（屬性）-Value（值）資料模型，将傳統的 ORM 映射模型——即實體屬性與資料庫表字段一一對應的模型，變換為實體屬性與資料表的行記錄一一對應的模型。EAV 模型大大增加了資料映射和相關業務邏輯的複雜程度，但是具備高度的靈活性，能夠滿足随時變化的資訊結構，滿足動态變更的實體結構、滿足字段級權限控制、滿足字段級資料版本曆史等功能。
2. 采用松散型資料結構的資料庫方案
其中的代表便是MongoDB：一個介于關系資料庫和非關系資料庫之間的分布式檔案存儲資料庫産品，在 CAP 理論中屬于 CP 範疇，支援松散資料結構，支援複雜的混合資料類型，支援 JSON 和文檔存儲。采用此方案的優勢比較明顯，除了能夠滿足 EAV 模型所具備的大部分功能外，還大大簡化了技術複雜度，支援分布式部署，推薦采用此方案。
3. 資訊分類
平台的資訊主要分為基礎資訊和業務資訊兩大類。基礎資訊分為個人實體資訊群組織實體資訊，主要描述實體的基本資訊、通用資訊，與業務相關性不大，例如姓名、性别、身份證号碼、手機号碼、企業通用資訊、企業工商資訊等。業務資訊由各業務系統自行管理和維護，UIMS 不涉及。
所有與資訊收集、儲存、處理及資料安全有關的書面政策，應當出具《隐私政策》并進行聲明。部分組織資訊由于可在網上公開查到，且是法定必須公布的資訊，是以可以預設公開。
四、其他功能子產品
1. 軟體授權
基于兩級賬戶體系，建立雲平台付費授權機制，針對使用者賬戶群組織賬戶進行獨立授權。根據産品的商業政策，可執行靈活的付費模式：
- 時效限制：年付、季付、月付，不同時效費用不同。
- 功能限制：授權不同的功能，費用不同。
- 數量限制：最大組織數量限制、最大使用者數量限制，不同的數量費用不同。
2. 組織入駐
UIMS 應提供一個組織實體注冊登記的流程，允許組織主動送出基本資訊，開戶入駐平台。此外，應提供在管理背景手工錄入組織開戶的功能。
3. 實名認證
分為個人賬戶實名認證群組織賬戶實名認證，盡量通過技術手段自動執行實名認證的稽核過程，減少甚至取消人工幹預。UIMS 應提供實名認證的功能和流程。
4. 資質稽核
資質稽核分為兩部分：一是部分實體實名認證過程中的人工核查；二是對實體送出的額外資質進行技術或人工稽核。
5. 組織綁定
基于『從屬關系隔離原則』，個人賬戶應在具體的業務系統中綁定組織賬戶，綁定過程分為兩種類型：一是由組織管理者手工建立的從屬個人賬戶，另一個是個人賬戶申請加入某個組織。業務系統應該提供此功能和流程。例如，個人注冊帳号後，可主動登記綁定組織，對已注冊登記的組織則要該組織管理者稽核，未在系統中注冊登記的組織，則始終處于待稽核狀态。
6. 組織解綁
允許個人賬戶解除與組織之間的從屬關系。解綁分為兩種情況：一是個人賬戶主動解除關系，二是組織管理者解綁、解雇或清除雇員（個人賬戶）。
其中第一種個人解綁的，應當由組織進行稽核準許，個人申請解除綁定關系，組織進行稽核，但是是否需要稽核，應交由具體的業務系統自行決定。
7. 間接雇傭（從屬）關系
雇傭（從屬）關系分為直接雇傭與間接雇傭關系。例如保安員在某保安公司入職（直接雇傭），在某物業作保安（間接雇傭）。考慮兩種辦法辨別間接雇傭關系。
8. 增加服務機關（項目點、物業社群）的實體概念
利用組織内部的組織機構體系，将間接雇傭機關作為目前組織的分支機構進行處理。
9. 賬戶登出
分為個人賬戶的登出群組織賬戶的登出。UIMS 應提供相應的頁面完成賬戶登出的操作。
10. 私有化部署
原則上拒絕私有化部署，但對于特定的客戶，考慮私有化部署。私有化部署須考慮版本更新問題，在軟體架構設計時，盡量遵循業務系統和技術系統分離的原則，并抽離公共子產品，最大限度為私有部署的版本提供更新服務。
五、總結
總體來說，統一身份管理系統要做的事情有這麼幾件：
1. 定義實體
2. 業務系統實體
3. 服務賬戶實體（用戶端）
4. 組織實體
5. 組織架構
6. 個人實體
7. 角色實體
8. 權限辨別
9. 資源辨別
10. 條件辨別
11. 處理上述各實體之間的關系，并提供資料結構
12. 提供鑒權API和業務 API
13. 提供其他功能：統一注冊功能（頁面和流程）、統一登入功能、軟體授權、組織入駐、組織綁定/解綁、資質審查。
本文由@劉同學 原創釋出于人人都是産品經理，未經許可，禁止轉載
題圖來自Unsplash，基于CC0協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。