本系列拙作是個人在公司業(yè)務(wù)中臺建設(shè)中的思考，共分為3篇（按中臺劃分），本篇為第一篇。由于中臺尚處于建設(shè)中，最終走向還待實踐。公司的產(chǎn)品有2B和2C方向，因此在設(shè)計時需要同時考慮這兩方面。

ps：我所聲稱的用戶中臺，可以認為是一個基于微服務(wù)的類SAAS的綜合身份管理中心，主要給公司平臺內(nèi)的業(yè)務(wù)系統(tǒng)使用。

問題域

用戶中臺需要面對哪些問題呢？

把時間線往前撥一下，先看看企業(yè)在信息化方面的遇到的問題，然后再看看用戶遇到的問題。

企業(yè)遇到的問題：

在多年以前，企業(yè)的業(yè)務(wù)系統(tǒng)是由各個部門負責(zé)建設(shè)，比如大家熟知的OA系統(tǒng)、財務(wù)系統(tǒng)、CRM和ERP等系統(tǒng)，這些系統(tǒng)是由某個部門提出然后并負責(zé)推向公司使用。

當(dāng)業(yè)務(wù)系統(tǒng)慢慢變多的時候就會發(fā)現(xiàn)，雖然企業(yè)擁有了這么多系統(tǒng)，但是這些系統(tǒng)的數(shù)據(jù)是不通用的。每個系統(tǒng)都需要把員工和組織錄入一遍。

一旦員工變動（變更組織或者辭職、新員工入職），那么所有業(yè)務(wù)系統(tǒng)都需要全部更新一遍，這無疑增加員工的工作。而且，由于這些系統(tǒng)互不相同，導(dǎo)致職員在上班時需要逐個登錄到相關(guān)系統(tǒng)，浪費不少時間。

更致命的是，有的員工離職之后，某些系統(tǒng)的操作人員沒能及時注銷員工賬號導(dǎo)致公司數(shù)據(jù)泄露；某些員工在離職前拷貝公司客戶數(shù)據(jù)導(dǎo)致客戶被挖墻腳，這些事情也屢見不鮮。

那么企業(yè)遇到的主要問題有（4A）：

• 統(tǒng)一管理員工賬號，為新員工創(chuàng)建賬號，為離職員工注銷賬號；
• 統(tǒng)一管理員工權(quán)限，避免員工越權(quán)接觸數(shù)據(jù)或越權(quán)操作等；
• 統(tǒng)一認證，所有系統(tǒng)只需要登錄一次；
• 統(tǒng)一審計，記錄所有員工的 操作日志。

除了這些企業(yè)內(nèi)部遇到的問題外，還有一些是對外暴露的一些問題：用戶在A產(chǎn)品上的賬號不能在B 產(chǎn)品上登錄，盡管A產(chǎn)品和B產(chǎn)品都屬于同一個公司。

那么回到一個用戶中臺（類似SAAS），不僅要面對上述問題，還需要處理以下問題——組織如何注冊。

• 組織如何實名
• 組織如何登錄（組織管理員如何登錄）
• 員工怎么登錄，手機密碼、手機短信驗證碼、第三方登錄（微信、QQ、微博等）、賬號名稱/ID
• 怎么創(chuàng)建、刪除、禁用員工賬號
• 管理員怎么邀請員工加入到這個虛擬“組織”
• 組織如何分配員工權(quán)限（控制訪問）

用戶遇到的問題：

用戶面對的問題與企業(yè)是有一些類似，明明用的都是某一個公司的產(chǎn)品，結(jié)果卻需要用戶再次注冊；更有甚者web端和移動端不統(tǒng)一，導(dǎo)致用戶在web端下的單但是在手機上卻看不著。

如果沒有統(tǒng)一的用戶管理，付出的代價也是非常昂貴的，用戶流失是一方面，用戶打通的成本是另一方面。比如最近2年阿里推出的88vip，其中一個目的就是為了打通阿里系相關(guān)產(chǎn)品的用戶體系。

對于用戶，重點是以下問題：

• 需要登錄么
• 怎么登錄，手機密碼、手機短信驗證碼、第三方登錄（微信、QQ、微博等）
• 怎么注冊，手機號注冊、郵箱注冊
• 怎么能夠注銷賬號
• 是否需要實名，如何實名

解決方法域

對于問題域中提及的問題，業(yè)內(nèi)其實有很成熟的解決方案，比如4A管理和IAM。

4A管理：集中賬號管理（Account）、集中認證管理（Authentication）、集中授權(quán)管理（Authorization）和集中審計管理（Audit）

IAM：Identity and Access Management，即身份識別與訪問管理

當(dāng)然類似的公開產(chǎn)品有（非公開的更多）：

• 東軟 SaCa IAM
• 國民認證的統(tǒng)一身份認證平臺（UAP）
• 其它的就不列舉了

無論哪種解決方案，重點要解決的問題是：

• 統(tǒng)一管理賬號，創(chuàng)建賬號、注銷賬號、修改密碼、找回密碼、修改信息等等
• 統(tǒng)一管理權(quán)限
• 統(tǒng)一登錄
• 統(tǒng)一注冊
• 統(tǒng)一認證鑒權(quán)

設(shè)計思路

在分享設(shè)計思路之前先定義一些概念

概念

下面是一些概念（來源于關(guān)于SaaS平臺中應(yīng)對多租戶模式的設(shè)計—權(quán)限設(shè)計）：

（1）資源

被安全理的對象（Resources頁面、菜單、按鈕、訂單等）。

（2）權(quán)限

訪問和操作資源的許可（Permit刪除、編輯、審批等）。

（3）角色

用戶通過業(yè)務(wù)需求確定一個角色（Role），并按照實際的業(yè)務(wù)場景，賦予角色對應(yīng)的權(quán)限的過程，角色也可以理解是權(quán)限的集合，是眾多權(quán)限顆粒組成。

（4）用戶

系統(tǒng)實際的操作員（User）

（5）操作權(quán)限

• 頁面權(quán)限：即用戶登錄系統(tǒng)可以看到的頁面，由菜單來控制，菜單包括一級菜單或多級菜單。當(dāng)系統(tǒng)賦予用戶對應(yīng)菜單的權(quán)限，那么用戶就可以訪問對應(yīng)的菜單頁面。
• 操作權(quán)限：即頁面的功能按鈕，包括：查看、新增、修改、刪除、審核等。當(dāng)用戶點擊按鈕時，系統(tǒng)將會校驗用戶的是否包含次操作權(quán)限，如果有，就可以進行下一步操作。
• 數(shù)據(jù)權(quán)限 ：數(shù)據(jù)權(quán)限就是用戶在同一頁面看到的數(shù)據(jù)是不同的。比如項目管理員，就能看到當(dāng)前團隊正在進行中的項目，以及項目的進度情況。而團隊成員，就只能看到本人具體參與的項目以及項目信息。相對于復(fù)雜一項的權(quán)限也可以基于組織結(jié)構(gòu)來拓展。

注意：在用戶中臺中，資源歸屬于各業(yè)務(wù)系統(tǒng)，但權(quán)限（權(quán)限控制）卻是屬于用戶中臺！

關(guān)于統(tǒng)一管理的說明：

這里面的統(tǒng)一管理是從開發(fā)角度或者系統(tǒng)治理角度出發(fā)，并非是從使用角度出發(fā)。

以權(quán)限管理為例，之前每個業(yè)務(wù)系統(tǒng)需要搭建自己的權(quán)限管理，10個系統(tǒng)就需要開發(fā)10次 。如果將這些分散在各系統(tǒng)中的權(quán)限管理合并到某個系統(tǒng)中，那么只需要開發(fā)一次即可。

而這個獨立的權(quán)限管理系統(tǒng)就可以稱之為統(tǒng)一權(quán)限管理系統(tǒng)。這個統(tǒng)一的管理系統(tǒng)可以由專人/部門維護，也可以由各個系統(tǒng)來維護。

從使用角度上來看，統(tǒng)一權(quán)限就是有專門的人負責(zé)給平臺所有用戶分配權(quán)限，比如新來一個研發(fā)小張，公司信息部給他創(chuàng)建賬號并給他分配各系統(tǒng)的權(quán)限。這個信息部就承擔(dān)了統(tǒng)一管理的角色。

以“用戶”為中心

用戶中臺是以“用戶”為中心的，那么可以基于用戶的活動來繪制一張“用戶地圖”，如下圖所示。

從圖中可以看到，用戶屬于用戶中臺，但是他在物業(yè)系統(tǒng)中的角色是管理員，在智慧園區(qū)系統(tǒng)中的角色是普通員工。這表明著用戶在不同的業(yè)務(wù)系統(tǒng)中承擔(dān)著不同的角色，換句話說，角色是與系統(tǒng)關(guān)聯(lián)，系統(tǒng)限定了用戶的角色。

上圖有一個明顯的問題，這個用戶沒有屬于任何組織或者只屬于一個組織（平臺方）。如果僅是一個自用的平臺、小團隊等等，沒有顯式的組織是有可能的。但是，有人的地方就會有團隊，有團隊的地方就會有組織（有人的地方就有江湖）。

而軟件系統(tǒng)是人類真實社會的一個寫照一個映射，組織自然就應(yīng)該加上。用戶可以屬于1個組織也可以屬于多個組織，這些組織之間可以是相關(guān)聯(lián)（比如集團公司和子公司），也可以不關(guān)聯(lián)（比如特朗普不僅是總統(tǒng)，還是商人）。用戶與組織的關(guān)聯(lián)關(guān)系后面再詳細介紹。

由于我們的部分業(yè)務(wù)是對外提供服務(wù)（SAAS），用戶中臺還要考慮多租戶需求。各租戶的權(quán)限控制可能不一樣，組織架構(gòu)也可能不一樣，因此需要進一步調(diào)整以應(yīng)對這兩種挑戰(zhàn)。

這會遇到一個問題，若租戶使用多個系統(tǒng)，那么是每個系統(tǒng)都創(chuàng)建組織還是所有系統(tǒng)都使用一個組織？

個人比較大傾向于各個系統(tǒng)使用獨立的組織（指組織機構(gòu)），這樣會更靈活一些（有的業(yè)務(wù)系統(tǒng)不需要組織架構(gòu)，而有的業(yè)務(wù)系統(tǒng)需要組織架構(gòu)來劃分各種權(quán)限尤其是數(shù)據(jù)類權(quán)限）

此處是分割線……

如果不存在多租戶概念，那就沒有租戶這一層。這種更接近于自用的內(nèi)部平臺，此時用戶應(yīng)當(dāng)與組織關(guān)聯(lián)（下圖未畫用戶與組織的關(guān)聯(lián)）

如果沒有組織（組織架構(gòu)）這一層，那么還可以簡化為：

賬號體系

從平臺角度上來看，平臺的賬號分為兩類，一類是個人賬號，一類是組織賬號（組織有政府機構(gòu)、企業(yè)、社會團體等）。個人賬號非常常見，全部的C端應(yīng)用和部分B端應(yīng)用都是基于個人賬號體系的。

關(guān)于組織賬號其實在一些平臺中也是非常常見的，銀行有公司賬號和個人賬號，支付寶和微信也有類似的賬戶；蘋果的開發(fā)者賬戶有個人、企業(yè)之分。

在組織賬號的實現(xiàn)上其實有兩種方式：

• 一種是為組織創(chuàng)建獨立的賬號（曾經(jīng)在政府OA系統(tǒng)中設(shè)計過）；
• 一種是將個人賬號綁定到組織進而通過個人賬號來登錄。后者在平臺中非常常見，比如各類SAAS平臺

ps：在授權(quán)方面，個人賬號和組織賬號并無區(qū)別。

權(quán)限管理

用戶中臺的權(quán)限體系是基于RBAC概念，這個RBAC是基于資源的RBAC而非基于角色的RBAC。

各業(yè)務(wù)系統(tǒng)的權(quán)限是相互獨立的，沒有依賴關(guān)系

業(yè)務(wù)系統(tǒng)的權(quán)限遵從于基于資源的RBAC

數(shù)據(jù)權(quán)限受限于數(shù)據(jù)規(guī)則

權(quán)限并集：與 RBAC2 的靜態(tài)職責(zé)分離-角色互斥原則相反，平臺采用多角色權(quán)限取并集的設(shè)計。即在某個業(yè)務(wù)系統(tǒng)中，用戶可以擁有多個角色。此時用戶在該業(yè)務(wù)系統(tǒng)的權(quán)限等于各角色權(quán)限的并集

為滿足以上幾點，權(quán)限體系中必須有系統(tǒng)標識；數(shù)據(jù)資源權(quán)限中不僅有組織標識，還必須要有部門標識和創(chuàng)建者標識，部門標識和創(chuàng)建者主要是便于區(qū)分消費者和生產(chǎn)者。

ps：目前暫未設(shè)計用戶組和角色組概念

賬號體系和權(quán)限管理小結(jié)

賬戶體系和權(quán)限管理遵循以下原則：

個人賬戶統(tǒng)一原則：個人賬戶一次注冊，全平臺通用，類似于全網(wǎng)通行證和 SSO。

業(yè)務(wù)權(quán)限獨立原則：每個子系統(tǒng)的權(quán)限體系是獨立的，但是由用戶中臺統(tǒng)一管理維護?！簜€人賬戶統(tǒng)一原則』明確了賬戶體系是統(tǒng)一的，但是對于每個子系統(tǒng)而言，每個賬戶所能使用的功能和服務(wù)，所能查看的數(shù)據(jù)權(quán)限是獨立維護的。

組織實體隔離原則：不同的組織實體之間，是相互隔離，獨立管理的。每個組織實體可以自行組織自己的組織體系、賬戶體系和權(quán)限體系。不同的組織實體資源權(quán)限也是隔離的。

從屬關(guān)系隔離原則：個體賬戶與組織實體的從屬關(guān)系是基于單獨的業(yè)務(wù)系統(tǒng)存在的，『個人賬戶統(tǒng)一原則』明確的僅是個人賬戶的全網(wǎng)統(tǒng)一，但組織實體、從屬關(guān)系并沒有統(tǒng)一，并且是隔離的。

比如在 CRM 系統(tǒng)中，張三（用戶）從屬于 XXXX 公司（組織），但在 OA 系統(tǒng)中，張三（用戶）默認是不從屬于任何組織的，從屬關(guān)系受到具體業(yè)務(wù)系統(tǒng)的影響。

事實上，這個原則是非強制的，具體取決于各自的業(yè)務(wù)邏輯和業(yè)務(wù)場景。

如果要簡化從屬關(guān)系的管理，那么可以不遵循此原則，即個體賬戶與組織實體的從屬關(guān)系是全平臺統(tǒng)一的，與業(yè)務(wù)系統(tǒng)無關(guān)，但這會為降低平臺的靈活性和擴展性。靈活性和復(fù)雜度之間通常要做一個取舍。

擴展：

在序言中提及到的《平臺級SAAS架構(gòu)的基礎(chǔ)-統(tǒng)一身份管理系統(tǒng)》文章中，作者用的是OS-RBAC權(quán)限體系，其中O是Orgnization組織，S是Systerm系統(tǒng)。筆者解釋這個體系說明權(quán)限受組織和系統(tǒng)雙重約束。

這一點我是贊同的，權(quán)限是依賴于系統(tǒng)，數(shù)據(jù)依賴于組織。這個在多租戶體系中尤為明顯，A公司的管理員不能看到B公司的數(shù)據(jù)，因為A和B是兩個不同的組織；同樣，A公司的組織架構(gòu)、權(quán)限體系可以和B公司的完全不一樣。

考慮公司平臺的業(yè)務(wù)主要集中在自用和第三方開發(fā)者接入使用，短期內(nèi)（半年到一年內(nèi)）有租戶入駐的概率較低。為了降低復(fù)雜度，我降低了組織對權(quán)限的影響（設(shè)計和開發(fā)實現(xiàn)上兼顧）。

即在某個業(yè)務(wù)系統(tǒng)中，所有管理員的功能權(quán)限是一樣的（數(shù)據(jù)權(quán)限除外，因其受到組織影響）。

用戶類型

下圖來源于《平臺級SAAS架構(gòu)的基礎(chǔ)-統(tǒng)一身份管理系統(tǒng)》，這個里面概況的用戶類型非常詳細。我將組織用戶和行業(yè)用戶都放在了組織用戶概念中，與前文的組織賬戶對應(yīng)。

組織類型

《GBT20091-2006組織機構(gòu)類型》中定義了以下組織類型：

• 國家機關(guān)
• 企業(yè)
• 事業(yè)單位
• 社會團體（含行業(yè)協(xié)會）
• 其它類型

我們平臺對應(yīng)的2B業(yè)務(wù)有智慧社區(qū)、智慧園區(qū)、智慧辦公、智慧校園等，2C業(yè)務(wù)有智能家居、電商等。綜合這些業(yè)務(wù)場景，平臺首要考慮：

• 國家機關(guān)，園區(qū)、社區(qū)類需要考慮，尤其是引入政府資金時，可能需要將數(shù)據(jù)提供給街道辦、公安或政法委（綜治辦2018年被撤銷，相關(guān)事宜轉(zhuǎn)交到政法委）
• 電商平臺，主要考慮到企業(yè)類型

服務(wù)分解

微服務(wù)架構(gòu)下的服務(wù)分解有兩種方式：一種是基于業(yè)務(wù)能力的分解方式，一種是基于DDD領(lǐng)域驅(qū)動子域分解。由于我還在學(xué)習(xí)DDD領(lǐng)域驅(qū)動，故先基于業(yè)務(wù)能力來分解服務(wù)。

業(yè)務(wù)能力

用戶中臺需要滿足下列需求：

從功能角度來看，可以分為以下模塊，詳見腦圖：

• 賬戶
• 認證
• 組織管理
• 權(quán)限管理
• 授權(quán)管理
• 鑒權(quán)中心
• 系統(tǒng)管理

服務(wù)分解

以下是具體的服務(wù)

（1）賬號類服務(wù)

• 賬號管理服務(wù)
• 注冊服務(wù)
• 注銷服務(wù)

（2）權(quán)限類服務(wù)

• 角色服務(wù)
• 權(quán)限服務(wù)

（3）組織類服務(wù)

• 組織管理服務(wù)
• 組織機構(gòu)管理服務(wù)

（4）授權(quán)類服務(wù)

授權(quán)服務(wù)：綁定/解綁角色權(quán)限，綁定/解綁用戶角色，綁定/解綁用戶和系統(tǒng)，綁定用戶和組織機構(gòu)。

（5）鑒權(quán)類服務(wù)

• 登錄鑒權(quán)服務(wù)：登錄方式配置、登錄風(fēng)控和登錄鑒權(quán)3個業(yè)務(wù)能力
• 其它訪問鑒權(quán)：負責(zé)外部應(yīng)用訪問內(nèi)部服務(wù)的鑒權(quán)

（6）認證類服務(wù)

認證服務(wù)：包含個人實名認證、組織實名認證和人證資質(zhì)審核3個業(yè)務(wù)能力。

（7）系統(tǒng)類服務(wù)

系統(tǒng)管理服務(wù)：負責(zé)系統(tǒng)的增刪改查

參考鏈接

平臺級SAAS架構(gòu)的基礎(chǔ)：統(tǒng)一身份管理系統(tǒng)

關(guān)于SaaS平臺中應(yīng)對多租戶模式的設(shè)計—權(quán)限設(shè)計

本文@ wweiru 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，不得轉(zhuǎn)載。

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