在很多企業中，人員的身份信息管理可謂是一片混亂：身份信息存儲在多個不相連的信息源中，屬性格式也不同，若數據維護不及時或人工輸入出錯，不一致的信息就會導致大量的溝通成本和修復的混亂。這對於想要創建單一信息源以支持身份管理服務的IT團隊來說，是一項挑戰。
什麼是信息源和單一信息源？
Source of truth （SOT）
（身份）信息源，包含了所有賬號的屬性信息和具體數據。企業中可以有一個或多個信息源，例如AD、LDAP、HR或OA。每個信息源可能提供不同的身份屬性信息（例如姓名、電話、性別、職級等）。在連接外部應用時，可能會發生單個應用所需的身份屬性信息要去不同的信息源中調取的情況，十分繁瑣。
Single source of truth（SSOT）
單一（身份）信息源，在來自不同信息源的同一屬性信息中，作爲唯一的標準數據存在。
舉個例子：
由HR管理的HR系統中存儲了人員的姓名、郵箱、手機號三個屬性信息；由IT人員管理的OA系統中存儲了姓名、生日、手機號三個屬性信息。某員工只告知IT人員需更換手機號碼，IT人員在OA系統中進行了更新。所以，當使用以手機號爲準的應用時，OA所提供的手機號信息就是SSOT。
如果企業使用像釘釘這樣以手機號爲準的應用，需要對接OA； 再使用像office 365這樣以郵箱爲準的應用，又需要對接HR。更糟糕的是，一些對屬性信息要求複雜的應用則需要企業一次對接多個系統。另外，在實際對接中，只有少數專業人員知道哪個系統提供的信息最爲準確。不確定性+複雜性就會造成身份信息管理的混亂。
如何解決？
面對這個問題，首先企業應當確認針對每一個屬性信息的SSOT。接下來，需要找到一個可以統一所有信息源的目錄，彙集並梳理出所有標準數據，清除無效數據（這需要屬性的映射和轉換，我們在下一期文章中會具體解釋），形成一個完整可用的SSOT，並作爲身份管理服務的SSOT。
今天，玉符的產品之一已經實現了這個功能。這一期內容，我們就來講一講它：統一目錄
有人會問，“如果我的企業已經以AD/LDAP作爲目錄，且它能滿足我對單一信息源的要求，爲什麼我還需要統一目錄呢？”
AD/LDAP出現了困局
爲了對本地資源進行訪問控制，企業將本地部署應用集成到AD或LDAP。這時候，用戶可獲得最佳體驗：即用戶只需登錄一次用戶所在的域環境便可獲得其相對應資源的訪問權限。與此同時，管理員也會從中受益，他們可以精確的掌控每一個人對於每一個應用和資源的訪問權限。
這樣的認證架構是被廣泛應用的，因爲他非常適合完全的本地部署架構。但隨着企業大量採購和使用純的雲端應用，這種傳統的認證架構無法再適用。
無法適用的原因
從本地部署向雲部署應用過渡有一個副作用，就是企業不得不擴用多套獨立用戶目錄。通常來講，每個雲應用都是獨立運營的，因此擁有自己獨立的賬戶體系。如果企業只是採用一到兩個雲端應用，這只是小麻煩，但隨着公司使用越來越多的雲應用，管理員很難管理多個用戶目錄，當用戶密碼隨着每個新應用的出現激增時，管理員很快就會失去精確掌控每一個人對於每一個應用和資源的訪問權限的能力。
有關用戶目錄不斷增長的問題，唯一可行的解決方案就是將所有云應用集成到統一的目錄上。
直到今天，AD和LDAP都被視爲最便捷的用戶管理服務，因爲它們可以同時爲本地部署和雲端部署的應用提供身份管理。雖然一些雲服務提供商爲企業客戶提供相應的API或者開發套件幫助客戶繼續使用AD或LDAP，但是現在許多新應用和AD沒有原生支持，通過API進行集成需要大量的定製化開發。隨着雲應用數量的增加，這種針對每個應用進行AD或LDAP對接的模式變得成本極高，而且爲了滿足業務發展，企業總會不斷採用新應用。
所以，雖然AD和LDAP仍可用，但其過高的金錢和時間成本迫使企業尋找新的解決方案——基於雲的統一用戶目錄，也就是統一目錄。