UIMS即統(tǒng)一身份管理系統(tǒng)，可以認(rèn)為是多租戶架構(gòu)的升級(jí)版，通常是整個(gè)平臺(tái)賬號(hào)和權(quán)限管控的基礎(chǔ)性系統(tǒng)，可劃分為兩級(jí)賬戶體系、基礎(chǔ)權(quán)限模塊和基礎(chǔ)信息模塊三大模塊。本文從這三個(gè)方面對(duì)UIMS進(jìn)行了分析闡述，一起來(lái)看一下吧。

一、概述

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

1. 集中賬號(hào)管理（Account）
2. 集中認(rèn)證管理（Authentication）
3. 集中授權(quán)管理（Authorization）
4. 集中審計(jì)管理（Audit）

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

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

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

從整個(gè)平臺(tái)的角度來(lái)看，UIMS 除了提供上述功能和服務(wù)，還應(yīng)該滿足以下需求：

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

1. 功能

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

2. 系統(tǒng)標(biāo)識(shí)管理System Identifiers Management

3. 服務(wù)賬戶管理Service Accounts Management

4. 賬戶實(shí)體管理Account Entities Management

5. 組織實(shí)體管理Organization Entities Management

6. 組織架構(gòu)管理Organization Management

7. 個(gè)體賬戶管理Individual Accounts Management

8. 賬戶權(quán)限管理Account Permissions Management

9. 用戶組管理User Group Management

10. 角色管理User Roles Management

11. 資源權(quán)限管理Permission Resources Management

12. 權(quán)限策略組管理Permission Group Management

13. 認(rèn)證審核管理Authentication Management

14. 個(gè)人認(rèn)證管理Individual Authentication Management

15. 組織認(rèn)證管理Organization Authentication Management

16. 資質(zhì)審核管理Qualification Management

17. 付費(fèi)授權(quán)管理Authorization Management

18. 組織授權(quán)管理Organization Authorization Management

2. 頁(yè)面

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

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

3. 組織入駐頁(yè)面Organization Signup Page

4. 個(gè)人實(shí)名認(rèn)證頁(yè)面Individual Authentication Page

5. 組織實(shí)名認(rèn)證頁(yè)面Organization Authentication Page

3. API

1. 鑒權(quán)相關(guān)的API

2. 業(yè)務(wù)相關(guān)的API

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

二、兩級(jí)賬戶體系和基礎(chǔ)權(quán)限模塊

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

個(gè)人實(shí)體可以從屬于組織實(shí)體（可以從屬于多個(gè)組織實(shí)體），也可以不從屬。個(gè)人賬戶體系和組織賬戶體系在云平臺(tái)內(nèi)享有的權(quán)限是不一樣的，雖然大部分功能和服務(wù)兩個(gè)體系的實(shí)體均可獨(dú)立使用，互不干擾，但部分功能和服務(wù)有所不同。

1. 原則

1）基本原則

平臺(tái)級(jí)SAAS 模式賬戶體系應(yīng)遵循以下幾個(gè)基本原則：

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

個(gè)人賬戶一次注冊(cè)，全平臺(tái)通用，類似于全網(wǎng)通行證和SSO，注冊(cè)和登錄都在 UIMS 進(jìn)行。

②業(yè)務(wù)權(quán)限獨(dú)立原則

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

③組織實(shí)體隔離原則

不同的組織實(shí)體之間，是相互隔離，獨(dú)立管理的。每個(gè)組織實(shí)體可以自行組織自己的組織架構(gòu)、賬戶體系和權(quán)限體系。不同的組織實(shí)體資源權(quán)限也是隔離的。

④從屬關(guān)系隔離原則

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

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

2）權(quán)限原則

類似于 RBAC 原則，平臺(tái)的權(quán)限體系采用 OS-RBAC 的概念：

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

2. RBAC：基于角色的訪問(wèn)控制。

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

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

5. 條件標(biāo)識(shí)：權(quán)限的約束條件，主要有可見(jiàn)組織架構(gòu)范圍限定、時(shí)間限定、區(qū)域限定等。例如某權(quán)限僅財(cái)務(wù)部可見(jiàn)，有效期至11月2號(hào)，這里『財(cái)務(wù)部』屬于可見(jiàn)組織架構(gòu)范圍限定，『至11月2號(hào)』則是時(shí)間限定。

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

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

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

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

表1RBAC模型

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

[1]業(yè)務(wù)系統(tǒng)標(biāo)識(shí)；

[2]條件標(biāo)識(shí)：時(shí)間限定；

[3]組織實(shí)體標(biāo)識(shí)；

[4]條件標(biāo)識(shí)：可見(jiàn)組織架構(gòu)范圍限定；

[5]條件標(biāo)識(shí)：區(qū)域范圍限定；

[6]資源標(biāo)識(shí)；

[7]權(quán)限類型。

2. 從屬關(guān)系

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

1．業(yè)務(wù)系統(tǒng)（系統(tǒng)標(biāo)識(shí)）

2．服務(wù)賬戶（客戶端）

3．個(gè)人賬戶實(shí)體

4．組織賬戶實(shí)體

5．組織架構(gòu)

6．用戶組（非必選項(xiàng)）

7．角色實(shí)體

8．權(quán)限實(shí)體

9．資源實(shí)體

10．限定條件實(shí)體

11．權(quán)限策略組（非必選項(xiàng)）

1）與組織實(shí)體強(qiáng)關(guān)聯(lián)的實(shí)體

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

由于組織架構(gòu)不能脫離組織實(shí)體單獨(dú)存在，因此當(dāng)用戶實(shí)體綁定組織架構(gòu)時(shí)，該用戶實(shí)體必須隸屬于該組織架構(gòu)所從屬的組織實(shí)體。同理可知以下從屬關(guān)系遵從同樣的約束——即每對(duì)關(guān)系的兩個(gè)實(shí)體對(duì)象必須屬于相同的組織實(shí)體：

2）與業(yè)務(wù)系統(tǒng)強(qiáng)關(guān)聯(lián)的實(shí)體

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

3. 實(shí)體類型

基于以上各項(xiàng)原則，實(shí)體類型又分為以下幾種情況：

1）組織實(shí)體（未認(rèn)證）

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

2）組織實(shí)體（已認(rèn)證）

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

3）個(gè)人實(shí)體（未認(rèn)證）

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

4）個(gè)人實(shí)體（已認(rèn)證）

與組織實(shí)體（已認(rèn)證）類似。

5）個(gè)人實(shí)體（未從屬于組織）

未從屬組織的個(gè)人實(shí)體賬戶，與上述個(gè)人實(shí)體類型一致。

6）個(gè)人實(shí)體（從屬單個(gè)組織）

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

7）個(gè)人實(shí)體（從屬多個(gè)組織）

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

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

8）組織管理員

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

4. 用戶分類

表2用戶分類

5. 組織分類

表3組織分類

三、基礎(chǔ)信息模塊

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

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

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

2. 采用松散型數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)庫(kù)方案

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

3. 信息分類

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

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

四、其他功能模塊

1. 軟件授權(quán)

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

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

2. 組織入駐

UIMS 應(yīng)提供一個(gè)組織實(shí)體注冊(cè)登記的流程，允許組織主動(dòng)提交基本信息，開(kāi)戶入駐平臺(tái)。此外，應(yīng)提供在管理后臺(tái)手工錄入組織開(kāi)戶的功能。

3. 實(shí)名認(rèn)證

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

4. 資質(zhì)審核

資質(zhì)審核分為兩部分：一是部分實(shí)體實(shí)名認(rèn)證過(guò)程中的人工核查；二是對(duì)實(shí)體提交的額外資質(zhì)進(jìn)行技術(shù)或人工審核。

5. 組織綁定

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

6. 組織解綁

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

其中第一種個(gè)人解綁的，應(yīng)當(dāng)由組織進(jìn)行審核批準(zhǔn)，個(gè)人申請(qǐng)解除綁定關(guān)系，組織進(jìn)行審核，但是是否需要審核，應(yīng)交由具體的業(yè)務(wù)系統(tǒng)自行決定。

7. 間接雇傭（從屬）關(guān)系

雇傭（從屬）關(guān)系分為直接雇傭與間接雇傭關(guān)系。例如保安員在某保安公司入職（直接雇傭），在某物業(yè)作保安（間接雇傭）。考慮兩種辦法標(biāo)識(shí)間接雇傭關(guān)系。

8. 增加服務(wù)單位（項(xiàng)目點(diǎn)、物業(yè)社區(qū)）的實(shí)體概念

利用組織內(nèi)部的組織機(jī)構(gòu)體系，將間接雇傭單位作為當(dāng)前組織的分支機(jī)構(gòu)進(jìn)行處理。

9. 賬戶注銷

分為個(gè)人賬戶的注銷和組織賬戶的注銷。UIMS 應(yīng)提供相應(yīng)的頁(yè)面完成賬戶注銷的操作。

10. 私有化部署

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

五、總結(jié)

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

1. 定義實(shí)體

2. 業(yè)務(wù)系統(tǒng)實(shí)體

3. 服務(wù)賬戶實(shí)體（客戶端）

4. 組織實(shí)體

5. 組織架構(gòu)

6. 個(gè)人實(shí)體

7. 角色實(shí)體

8. 權(quán)限標(biāo)識(shí)

9. 資源標(biāo)識(shí)

10. 條件標(biāo)識(shí)

11. 處理上述各實(shí)體之間的關(guān)系，并提供數(shù)據(jù)結(jié)構(gòu)

12. 提供鑒權(quán)API和業(yè)務(wù) API

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

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

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

該文觀點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。