現如今，云計算可以說正在推動著新的安全服務呈現爆炸似增長，但并不是每家企業都能夠同樣挖掘到，并充分利用這一趨勢。盡管身份即服務(IDaaS)和云計算正在改變著中小型企業的市場競爭游戲規則，而那些財富1000強的企業鑒于其自身龐大的規模和復雜性的熱特點，使得這些已經創建了多年的老字號企業難以徹底的超越其邊界安全。他們的客戶群可能已經覆蓋了全局范圍，但其基礎設施架構是如此的復雜——因此，確保這些基礎設施架構的安全是最為重要的——畢竟，這些公司并不具備將其導航到新的服務層的敏捷性。

既然規模較小的企業可以很容易地將他們的身份基礎設施實施外包，但為什么對于大型企業而言，想要遷移到云服務就變得如此的困難呢?今天，當涉及到應用程序和安全時，規模可觀的大型企業正面臨著兩種不同的發展趨勢。首先，他們需要負責為更多的來自不同地理位置、采用更多不同的設備、提供比以往任何時候都更多的應用程序的安全訪問。第二，身份數據源的數量和表現的多樣性——LDAP、AD、SQL、API——也正在以相同的速率瘋狂增長，而這種瘋狂增長的速率可謂是指數級的。

如此多的異質性正推動著傳統的身份識別和訪問管理(IAM)超出了突破點的邊界，而此時，確保訪問的安全性正變得越來越重要，而鑒于當前身份系統的復雜性和高度分散的特點，這一點也越來越難以保證。所有這一切帶來了一個經典的n-squared的問題，即許多企業正試圖通過很多的硬編碼以便將許多不同的數據來源連接起來，每個都有自己的安全協議和數據訪問要求。其所導致的結果是：成本昂貴的定制部署和更大的復雜性。



不同的數據存儲和應用程序之間的自定義編碼連接的成本可能是非常昂貴的。

好消息是：在跨Web和云應用程序的安全性和單點登錄(SSO)領域，這個n到n的問題正推動著諸如安全斷言標記語言(SAML，SecurityAssertionMarkupLanguage)、OAuth和OpenID連接等聯盟標準的快速普及應用。但是，許多企業發現，較之訪問一些“抽象”的身份提供者的簡單的聯盟要求，部署聯盟標準的要求更多。



雖然聯盟標準匯集整合了對于身份提供商的訪問，但身份集成整合往往需要為您的身份提供商提供有凝聚力的觀點，以匹配使用應用程序的需要。

為了促成這個解決方案的操作，需要某種形式的智能規范化和身份數據的整合。對于那些并非是待開發部署，其身份信息是存在于一個獨特的、有效驗證狀態的已經成立多年的大企業而言，是一個很大的挑戰。

在理想的狀態下，身份提供者應該能夠為身份驗證請求調用一個單一的標準化的身份驗證。但大多數財富1000強企業都正在處理分散的身份基礎設施的問題，其中身份數據信息和屬性是分散在不同的身份數據存儲的。身份提供者的目的并非是要跨數據孤島或理清協議差異來找到用戶和用戶重疊(雖然有產品做到了這一點)。其需要一個統一的，標準化的身份視圖，以便可以驗證用戶，并發出相應的指令，連接這些用戶到網絡或在安全邊界以外基于云的應用程序。

但是，對于大多數大型企業而言，跨多種不同的分布式架構提出一個全局性的用戶視野并不是一個快速或簡單的任務。您所需要的是某種形式的集成層，其也可以聯合您企業的身份來源——如同SAML和其他聯盟成員訪問協議本身一樣。所有這些數據源必須是聯合的，因為每一個都包含需要從現有數據中進行協調的屬性或身份信息片段。畢竟，在過去，沒有財富1000強公司曾開始過他們在這方面的業務。



在聯合層集成和協調身份。

并非要在所有這些復雜性之上強加一個獨特的集中式系統，一個聯合您身份數據源的整合應能夠提供整個系統的合理化觀點，所有用以響應新的需求和機會所需要的靈活性。通過整合跨數據孤島的身份數據和屬性，這種聯合身份層建立并維護了一個全局性的用戶列表，能夠跨所有企業系統實施動態策劃，然后映射數據，以滿足各個消費應用程序的獨特要求。

借助一個聯合身份層，您的身份提供者可以對身份實施一種理性的，普遍的驗證，同時每個用戶對于其自己的數據都有存儲維護自主權。當然，任何變更都將需要自動同步，并最好盡可能接近實時的自動同步。通過跟蹤所有用戶及其相關身份信息，包括多個或重疊的用戶名，這個聯合身份層可以幫助實現所有應用程序的快速，準確的身份驗證和授權。

如下，是當企業在建立聯合身份層時牢牢記住的幾項基本步驟。

1、盤點當前的數據源，并提取和統一元數據

構建一個身份集成整合層的第一步是要對于您企業所有的終端有一個充分的了解。您需要對所有您企業正擴展訪問的用戶存儲進行盤點，同時要了解每款應用程序在底層是如何與這些存儲交互的，包括其如何驗證和收集授權信息，以及它們發送了哪些查詢，它們期望哪類層次結構。一旦這一步完成了，您的整合層就可以開始了解數據的關系了(例如，在存儲中是否有相同的用戶，以及這些重復帳戶將如何進行協調)，使其能夠跨整個企業的每一個應用程序以所需要的方式提供完整的身份信息。

大型企業往往跨存儲庫陣列存儲身份和屬性信息，每個使用不同的協議和數據模型。一款智能聯合身份系統則應能彌合這些不同的系統，以創建一個通用對象模型。這樣的系統必須能夠發現并提取元數據，或身份信息，并讓每個數據源映射該信息到一個共同的命名。這是能夠讓關聯身份信息和由應用程序消耗的格式代表唯一身份信息的關鍵。如果跨整個數據源沒有用戶的重疊，所有身份的一個集合通常是足夠的。如果相同用戶位于多個數據源，則需要關聯邏輯以連接這些常見的帳戶，使它們在虛擬視圖僅代表一次。

2、聚合和關聯身份信息，以建立一個獨特的參考列表

當大型企業在嘗試遷移到云服務時，他們所面臨的其中一個主要挑戰不僅僅是多個用戶存儲的問題，而是跨越這些存儲的用戶重疊的問題。這是建立聯盟身份的一個主要障礙。理想的身份驗證的基礎是一份單一的全局用戶列表，其中每個用戶只有一個賬號，而沒有跨所有那些用戶可能散落的不同地方的多個不同的列表。您會希望所有的用戶屬性位于同一個邏輯位置進行授權。

解決方案是創建一個包含了所有用戶配置文件信息的單一列表，而做到這一點的最佳方式則是通過整合跨所有身份存儲的身份信息。一旦您的庫存盤點完成了之后，您可以從您的后端開始提取模式，然后關聯相同的用戶以創建一份全局名單。

對于最靈活的系統，映射所有的身份模式到一個共同的命名結構，并跨身份筒倉關聯相同的用戶帳戶是必不可少的，以便使得中全局用戶列表中沒有重復的身份。在用戶位于多個數據源的情況下，系統應該保持鏈接到本地身份標識符。這使得在認證過程中，系統的認證檢查功能更有效——這是加快認證過程，促成單點登錄的關鍵步驟。而不是執行一個耗時的，需要對所有的數據源執行循環搜索的過程，系統只需檢查用戶存儲有帳戶的這些庫。

3、加入身份來創建全局配置文件

一旦創建了全局列表，您可以通過加入操作所有本地帳戶的屬性，以豐富用戶的配置文件。不同的應用需要一個用戶身份信息的不同方面，所以重要的是要結合所有來源的認證和授權到一個全局配置。通過聯合所有的身份來源，您可以加入這些方面以形成一個全局配置，使得身份提供者能夠很容易地訪問，封裝打包到安全指令，用于消費應用程序。

對于具有重疊身份的每個用戶，集成層應該能夠從原始身份源和包括它們的全局配置文件提取所有屬性。證書應保存在原始數據源，而身份相關確保具有類似名稱的用戶不會被授予不當授權。

4、合理化群組

不必在多個源進行搜索，以找到群組和成員，身份提供者應該只需要搜索集成層以檢查群組成員，超速登錄和訪問。如果您企業的現有群組足以滿足今天強制執行的政策，當您在部署聯合身份層時不應該重做任何工作。這層應該虛擬化現有的群組，通過翻譯和DN(專有名稱)進行自動重映射。

當基于群組成員進行授權時，聯合身份層應該能夠合理化和匯總現有的群組，如果需要的話，扁平化嵌套組，甚至跨多個數據源的群組成員執行計算動態。其也應該讓您計算“成員”的價值，定義群組和用戶的條目本身之間的關系。

5、緩存速度和可擴展性造成的視圖

一種高級的身份集成整合層位于您企業當前目錄基礎設施及其所訪問的應用程序之間，從后端隔離變化。該層需要高度的可用性，可擴展性和快速的交付——有時甚至比底層的后端更快，以便為所有用戶提供對于應用程序快速和可靠的訪問，無論這些應用程序位于何處;是如何存儲的。

這樣的一個層也應該能夠提供一個基于您企業的部署要求和環境的持久性高速緩存的選擇，所以輸入、查詢、或建模視圖均可以緩存，以實現更高的性能和可用性，實時的或基于一個預定安排。物化層次視圖的持久性意味著查詢性能將不再受到復雜的連接和跨多個數據源的搜索所限制。



一份關于聯合身份層在聯合設計中適應的架構建議

借助一個聯合身份層，大型企業可以在簡化其身份基礎設施的同時，關心其現有的投資，使其更容易為自己的身份供應商提供信息，并安全地兌現聯合的承諾。但這一層還提供了一個靈活的基礎設施和架構模式，超越了聯合所帶來的直接挑戰，使得許多其他的用例，如Web訪問管理認證、為高度安全性要求數據的細粒度授權或應用程序、完整的客戶檔案、更快的應用部署，甚至并購整合變得更容易。構建一個身份整合層可以解決聯盟的挑戰，同時使企業能夠解決未來可能出現的任何新的挑戰。