雲計算設計模式(九)——聯合身份模式


雲計算設計模式(九)——聯合身份模式

驗證委托給外部身份提供者。這種模式可以簡化開發最大限度地減少用戶管理的要求並提高應用程序的用戶體驗

背景和問題


用戶通常需要使用提供,並通過與它們商業關系的不同組織主持的多個應用程序一起工作但是,這些用戶可能被迫使用特定的(不同的的憑證,每一個可以:
原因脫節的用戶體驗用戶經常忘記登錄憑據時,他們有很多不同的的。
暴露安全漏洞當用戶離開公司帳戶,必須立即取消設置這是很容易忽略這在大型組織中
復雜的用戶管理管理員必須管理憑據的所有用戶,以及執行等方面提供密碼提示的其他任務。

用戶會相反,通常期望使用相同的憑證用於這些應用

解決方案


實現了可以使用聯合身份的認證機制。從應用程序代碼中分離的用戶身份驗證和身份驗證委派到受信任的身份提供者可以大大簡化開發,讓用戶使用更廣泛的身份提供者國內流離失所者),同時最大限度地減少管理開銷進行身份驗證。它也可以讓你清楚地分離的授權認證

可信身份提供者可能包括公司目錄內部部署聯合身份驗證服務其他安全令牌服務STS的業務合作伙伴提供的社會身份提供者可以驗證誰擁有用戶例如,微軟,谷歌雅虎Facebook帳戶

圖1示出了當客戶端應用程序需要訪問要求身份驗證的服務聯合身份模式的原理。認證是通過身份提供者(IDP),在演唱其工作安全令牌服務(STS)的執行。境內流離失所者問題主張有關身份驗證的用戶的信息安全令牌該信息被稱為權利要求中,包括用戶的身份並且還可以包括其他信息,例如角色成員細粒度的訪問權限。

 

 

圖1  - 聯合身份驗證概述


該模型通常被稱為基於聲明的訪問控制。應用程序和服務授權訪問基於包含在令牌中的權利要求的特征和功能。要求身份驗證必須相信國內流離失所者服務客戶端應用程序的聯系人執行身份驗證境內流離失所者如果認證成功,則的IdP返回包含用於識別用戶於STS權利要求書的令牌(注意的IdP和STS可以是相同的服務)。在STS可以改變和增大根據預定義的規則,令牌中的權利要求書,將其返回到客戶端之前然后,客戶端應用程序可以將此令牌傳遞給服務作為其身份證明

注意:

某些情況下可能會有額外的STS的信任例如微軟Azure的場景描述后,內部部署STS信任STS另一個負責訪問身份提供者對用戶進行認證這種方法企業的情況普遍,其中有一個本地STS和目錄



聯合身份驗證提供了一個基於標准的解決方案,在不同信任身份的問題並且可以支持單點登錄它正在成為在所有類型的應用特別是雲托管的應用越來越普遍,因為它支持,而不需要直接網絡連接身份提供單點登錄用戶不必輸入憑據為每一種應用這增加了安全性,因為它阻止訪問許多不同的應用程序所需的憑據的擴散,同時也隱藏了用戶的憑據所有,但原來的身份提供者應用程序只看到包含的令牌中的身份驗證信息

聯合身份也具有重大的優點,即人的身份憑證管理身份提供者的責任。應用程序或服務並不需要提供身份管理功能。另外,在企業環境中企業目錄不需要知道關於用戶提供它信任身份提供者,它去除了管理該目錄中的用戶身份所有的管理開銷。


問題和注意事項


設計實現聯合身份驗證的應用程序時考慮以下因素:
•身份驗證可以是一個單點故障如果您將應用程序部署到多個數據中心考慮部署身份管理機制,以相同的數據中心,以保持應用程序的可靠性和可用性
•身份驗證機制,可以提供工具來配置基於包含在認證令牌的作用索賠的訪問控制這通常被稱為基於角色的訪問控制(RBAC),並且它可以允許控制權訪問的功能和資源的更精細的水平
•與企業目錄,利用社會身份提供者通常不提供有關身份驗證的用戶以外的電子郵件地址,也許名稱的信息基於聲明的身份一些社會身份提供者Microsoft帳戶只提供一個唯一的標識符應用程序通常將需要保持注冊用戶的一些信息,並且能夠匹配該信息,包含在令牌中的權利要求書的標識符。典型地,這是通過一個注冊過程完成的用戶第一次訪問該應用程序,信息然后被注入到令牌作為每個認證附加的權利要求
•如果配置為STS多個身份提供者必須檢測身份提供者,用戶應該被重定向到身份驗證這個過程被稱為主領域發現。在STS可能能夠基於電子郵件地址或用戶,該用戶提供該用戶被訪問時,用戶的IP地址范圍,該應用程序的一個子域上的cookie中存儲的用戶的內容自動地執行此瀏覽器。例如,如果用戶微軟user@live.com輸入一個電子郵件地址在STS用戶重定向到Microsoft帳戶登錄頁面隨后的訪問中,STS可以使用cookie來表示最后登錄的Microsoft帳戶如果自動發現無法確定主領域時,STS將顯示一個家庭領域發現HRD),其中列出了受信任的身份提供者,用戶必須選擇他們想要使用的人。

何時使用這個模式


模式是非常適合的范圍內情況下,如:
在企業單點登錄在這種情況下,您需要驗證員工托管在雲中企業安全邊界以外的企業應用程序而不需要他們每次訪問應用程序時簽署用戶體驗是一樣的使用本地應用程序,他們簽約到公司網絡時,最初通過身份驗證的時候從此獲得所有相關的應用程序,而無需再次登錄
與多個合作伙伴聯合身份在這種情況下,您需要驗證這兩個企業的員工和業務合作伙伴誰沒有公司目錄帳戶。這是企業對企業(B2B的應用程序集成與第三方服務,並在那里不同的IT系統公司合並或共享資源的應用普遍。
SaaS應用聯合身份在這種情況下獨立軟件供應商(ISV提供了一個即用型服務,為多個客戶租戶每個租戶將要使用適當的身份提供者進行身份驗證。例如企業用戶會希望我們自己的企業資格證書,租戶消費者和客戶可能希望使用自己的社會身份憑證。

這種模式可能不適合下列情況
應用程序的所有用戶都可以通過一個標識提供者進行身份驗證並沒有要求使用任何其他身份提供者進行身份驗證。這是典型只使用企業目錄進行身份驗證業務應用並獲得該目錄在應用程序中直接使用VPN或(在雲中托管的情況下),通過導通之間的虛擬網絡連接本地目錄和應用程序
•應用程序最初建使用不同的認證機制,或許與自定義用戶存儲或者不具有處理所用的權利要求為基礎的技術協商標准的能力。改造基於聲明的身份驗證和訪問控制到現有的應用程序可能很復雜,可能不符合成本效益。


例子


組織舉辦了多租戶軟件即Azure中的服務(SaaS)應用程序該應用程序incudes一個網站,租戶可以用它來管理應用程序為自己的用戶該應用程序允許租戶使用由活動目錄聯合服務ADFS產生的,當用戶通過該組織自己的Active Directory身份驗證的聯合身份訪問租戶的網站圖2示出了該過程的概述

 

圖2 - 用戶如何大型企業用戶訪問應用程序


在圖2所示的場景中商戶驗證自己的身份提供者步驟1)這種情況下ADFS在成功驗證租客ADFS發出的令牌。客戶端瀏覽器轉發令牌至SaaS應用聯合提供者,其信任租戶的ADFS發出令牌,以便取回的令牌是有效的SaaS的聯合提供者步驟2)。如果有必要在SaaS聯合會提供商上執行令牌中的權利要求書的權利要求應用程序識別新令牌返回給客戶機瀏覽器之前步驟3)的變換。應用程序信任SaaS的聯合提供者發出的令牌,並使用令牌中的權利要求書申請授權規則步驟4)。

租戶將不再需要記住不同的憑據來訪問應用程序以及管理員租戶的公司將能夠在自己的ADFS配置可以訪問應用程序的用戶的列表

本文翻譯自MSDN:http://msdn.microsoft.com/en-us/library/dn589790.aspx


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com