統一身份認證是整個 IT 架構的最基本的組成部分，而賬號則是實現統一身份認證的基礎。做好賬號的規劃和設計直接決定著企業整個信息系統建設的便利與難易程度，決定著能否敏捷和快速賦能，決定著數字化轉型的投入和效率。

用戶賬號是用戶身份的一種表示。傳統統一身份認證系統往往作為外圍系統來集成各個應用系統，而不是作為核心基礎系統被其他應用系統來集成。所以傳統統一身份認證系統的建設存在眾多的問題，使設計實現復雜化，管理復雜化，集成復雜化。

我們今天將詳細討論下統一身份認證賬號設計的幾個相關問題：

1. 賬號基礎數據來源及管理

賬號( Account )是統一身份認證系統中 4A 管理中的一個要素。賬號數據來源于哪里是建設統一身份認證平臺時首先要確認的問題。賬號通常可以簡單分為內部員工賬號和外部客戶 / 用戶賬號。內部賬號也可能包括工勤賬號、外包賬號、合作伙伴賬號等。外部客戶 / 用戶賬號則通常是業務客戶或用戶的賬號。內部和外部賬號通常是兩個領域的賬號管理需求，需要分別進行處理。因此統一身份認證平臺需要支持“多租戶”能力，以區分不同領域賬號管理或安全隔離要求。

內部賬號通常可以基于公司的 AD 或人力資源系統賬號為基礎，構建統一賬號管理能力。外部賬號則可以基于 CRM 系統賬號為基礎構建外部用戶統一賬號認證管理能力。在統一身份認證平臺內，表示用戶身份的賬號一定是唯一的。公司內部賬號往往是基于 AD 或 LDAP 的，統一身份認證平臺的賬號體系一旦建立起來，就可以替換掉 AD 或 LDAP ，不用再去集成 AD 或 LDAP 。身份認證賬號一定是處于最底層的，其他系統都要基于賬號體系來構建登錄認證的。

由于系統建設不可能一步到位，所以可能存在很多系統還是基于 AD 或 LDAP 進行賬號管理的，這就需要統一身份認證平臺提供臨時中間層，支持 LDAP 集成接口，以替換那些用到 AD 或 LDAP 的系統的配置。

賬號和用戶是兩個獨立的對象。賬號在統一身份認證平臺來維護，而用戶則往往在人力資源管理系統維護。在統一身份認證平臺內部，賬號可以關聯多種身份標識，以支持不同的認證方式或多因子認證。而人力資源管理系統等應用系統，則按照系統集成統一身份認證平臺的方式來實現。

2. 用戶管理

賬號管理可以很簡單，不包含用戶其他信息，只代表某個用戶的身份。就像人的身份證號一樣。不過用戶的信息通常是很多的，比如姓名、年齡等基本信息，還有教育背景、工作經歷、社會關系、培訓經歷、榮譽證書等信息。這些信息通常在人力資源系統里面進行維護管理。

從平臺融合微服務架構設計來說，統一身份認證平臺可以不需要考慮用戶信息的管理和維護。用戶管理可以單獨成為一個獨立的組件模塊或微服務組件，可以放在人力資源系統、 CRM 系統等來維護。通過用戶賬號和用戶信息關聯起來，先在統一身份認證平臺創建賬號，然后其他應用使用這個賬號進行數據結構、數據表設計和實現管理。

所有的用戶在統一身份認證平臺首先要根據規則生成賬號，比如員工賬號、外包賬號、供應商賬號等，然后賬號作為外鍵來關聯用戶其他相關信息。

(1) 賬號、用戶和用戶身份標識

用戶管理一定要首先為用戶創建賬號。存量系統中用戶都有賬號 /ID 標識，但由于每個系統每個應用都是一套獨立的賬號體系，形成數據孤島，帶來眾多的數據治理和數據使用問題，因此，通過構建統一的賬號體系來解決這些問題，減少重復建設，提升數字化效率。為用戶創建賬號后并為用戶綁定該賬號，則用戶就可以使用該賬號來標識自己的身份。賬號是用戶身份的一種標識。在統一身份認證平臺中，還會存儲其它用戶身份標識，比如人臉識別圖像信息用于人臉識別認證，指紋信息用于指紋認證，虹膜信息用于虹膜認證，手機號用于短信驗證碼認證等。這些身份標識都可以唯一標識一個用戶。

(2) 賬號和身份綁定

賬號可以是獨立的，用戶是獨立的對象，但用戶身份是和用戶相關聯的。首先要把賬號分配給用戶，然后采集用戶身份標識信息，比如指紋、人臉、手機號等，把賬號和用戶身份標識對應起來，從而提供了統一的身份認證能力。用戶可以選擇登錄認證方式來認證登錄。

3. 應用系統賬號集成

每個應用系統幾乎都有一套自己的賬號、權限體系。而且 IT 這么多年的建設，每家公司都有大大小小幾十套上百套系統。所以賬號、權限、日志等可能就重復建設了幾十次上百次。要建設統一身份認證體系，不得不集成這些大大小小的系統。那么該怎么集成?

我了解到的幾乎都是把數據復制一份導入到統一認證平臺。可能大家都習慣了數據導來導去，但這是我最反對的，最深惡痛絕的。那么多數據孤島、數據不一致、數據混亂等問題就是這樣造成的。很多人往往為了一時的便利根本不考慮其他，后期你不得不付出數倍數十倍的代價來解決這個問題。就像說句謊言，你不得不用十句百句來圓謊。

在討論正確的處理方法之前，我們需要明確在建設統一身份認證平臺時權限分層的問題。認識并理解用戶訪問權限的層級是認證體系建設的關鍵之一。

(1) 權限分層

首先統一身份認證平臺用戶登錄后，看到的是他能訪問的應用系統列表，比如一個人可以訪問 OA 、 CRM ，另外一個人可以訪問 OA 、 HR 系統。這是第一層的權限訪問控制。

其次，用戶進入特定的應用系統之后，有操作不同應用功能的權限。比如一個人能訪問 OA 系統的報表功能，另外一個人可以訪問 OA 系統除報表外的其他功能。不同的人在某個應用系統中的角色是不一樣的，角色對應的權限也就不一樣了。

(2) 新上線應用

對于新研發上線的應用，在研發之初就要使用統一身份認證平臺的賬號和權限體系，通過統一身份認證平臺提供的標準化接口來集成。這樣，所有的應用最終將融合為一個系統，每個應用相當于一個當前系統的一個組件模塊。

(3) 存量應用系統

統一身份認證平臺的賬號首先解決的是用戶登錄認證的問題。登錄之后訪問存量系統時，由于賬號可能存在不一致，這就需要在統一身份認證平臺內支持賬號映射能力，自動轉換為可訪問系統的內部賬號。這樣不用更改存量系統，只實現統一身份認證和單點登錄能力。

4. 賬號管理問題

在建設統一身份認證平臺時，我們不得不面對公共賬號、多賬號、賬號委托等問題。比如郵件系統的公共賬號、多賬號問題，業務系統的賬號委托問題等，這些問題都可以結合授權機制來處理。

(1) 賬號委托問題處理

在傳統的應用系統中經常會遇到賬號委托的問題，從身份認證和審計的角度來說是不合理的。賬號委托是把賬號直接賦予某個人來使用這個賬號，就像我可以拿著你的身份證去辦理一些事情，是以你的身份來辦理的，所以可能其他人并不知道是我操作的，從審計角度來說，就是你的行為，而不是我的行為。所以這是有問題的。

正確的做法是通過授權管理機制來實現。你可以把你的權限授權給我，我就有權限操作你能操作的業務功能。從審計角度來看，這是我的行為，也可以看到你授權給我了，所以我能代表你來做這些業務，如果有什么意外或不正確，可以通過審計記錄很容易定位到操作人。

功能實現并不難，難在思想和思維。一說要改變這些不正確的設計，很多人就會有很多藉口，要么推托業務要求，要么推托改起來太復雜等等，其實也就是不愿意改，怕改出問題。這樣就要求在數字化轉型提升應用效率的時候需要有全局規劃、頂層設計，通過開發人員自覺來完善幾乎是不可能的。

(2) 公共賬號問題

郵件系統等會涉及群組賬號，比如以某個部門或者團隊來發布通知。但必須明白，公共賬號是不可以通過統一身份認證來登錄的。公共賬號只和某個應用系統相關，是特定的需求，有特定的適用范圍，超過了這個范圍就是無效的。

因此公共賬號在統一認證平臺是不保存的。如果某些應用用到公共賬號，則可以在這些應用中來創建和維護，作為某個人的附屬賬號通過授權機制來進行管理和維護。也就是公共賬號可以在這個應用系統內部授權給某個人來使用，一旦超出了這個應用系統范圍則是無效的;同時也可以在需要的時候回收權限。

(3) 多賬號問題

既然有公共賬號，難免就需要有人來維護或代表這些公共賬號處理一些事情。但就像前面我們討論的公共賬號問題，一定是有范圍限定的。在統一身份認證平臺內，一個用戶的賬號是唯一的。只有具體到某個應用系統內，才會有多賬號問題，多賬號也就只限定在這個應用系統內。在統一身份認證平臺內部賬號映射管理時，可為該應用系統映射多個“內部賬號”(或可稱為“二級賬號”)，用戶訪問該應用系統時則可選擇用哪個“內部賬號”登錄。

5. 管理賬號/運維賬號問題

應用初始管理賬號和運維賬號也是需要考慮的。通常我們設置應用系統初始 admin 賬號，用 admin 來初始化應用系統。一旦通過角色權限設置管理員用戶， admin 賬號就需要被停用。在統一身份認證平臺，是不能映射用戶到應用 admin 賬號的， Admin 只是做初始化。后期的管理和運維都要用統一身份認證平臺的賬號，對應到具體的有身份的人。這樣才符合認證審計的要求。

很多人不理解建設統一身份認證平臺的初衷，僅僅把它當作一個系統實現單點登錄、雙因子認證等，更沒有認真考慮賬號管理等問題，而忽略了其潛在的價值。就像我們前面提到的，統一身份認證平臺是實現平臺融合的最基礎組件，只有設計好整個賬號體系，才能為后續的應用建設帶來敏捷和效率。