聯(lián)合身份模式

驗(yàn)證委托給外部身份提供者。這種模式可以簡(jiǎn)化開發(fā)，最大限度地減少對(duì)用戶管理的要求，并提高了應(yīng)用程序的用戶體驗(yàn)。

背景和問題

用戶通常需要使用由提供，并通過與它們有商業(yè)關(guān)系的不同組織主持的多個(gè)應(yīng)用程序一起工作。但是，這些用戶可能被迫使用特定的（和不同的）的憑證，每一個(gè)。這可以：

• 原因脫節(jié)的用戶體驗(yàn)。用戶經(jīng)常忘記登錄憑據(jù)時(shí)，他們有很多不同的的。
• 暴露安全漏洞。當(dāng)用戶離開公司的帳戶，必須立即取消設(shè)置。這是很容易忽略這在大型組織中。
• 復(fù)雜的用戶管理。管理員必須管理憑據(jù)的所有用戶，以及執(zhí)行等方面提供密碼提示的其他任務(wù)。

用戶會(huì)相反，通常期望使用相同的憑證用于這些應(yīng)用。

解決方案

實(shí)現(xiàn)了可以使用聯(lián)合身份的認(rèn)證機(jī)制。從應(yīng)用程序代碼中分離的用戶身份驗(yàn)證和身份驗(yàn)證委派到受信任的身份提供者，可以大大簡(jiǎn)化開發(fā)，讓用戶使用更廣泛的身份提供者（國內(nèi)流離失所者），同時(shí)最大限度地減少管理開銷進(jìn)行身份驗(yàn)證。它也可以讓你清楚地分離的授權(quán)認(rèn)證。

可信身份提供者可能包括公司目錄，內(nèi)部部署聯(lián)合身份驗(yàn)證服務(wù)，其他安全令牌服務(wù)（STS的）業(yè)務(wù)合作伙伴提供的，或社會(huì)身份提供者可以驗(yàn)證誰擁有用戶，例如，微軟，谷歌，雅虎或Facebook帳戶。

圖1示出了當(dāng)客戶端應(yīng)用程序需要訪問要求身份驗(yàn)證的服務(wù)的聯(lián)合身份模式的原理。該認(rèn)證是通過身份提供者（IDP），在演唱其工作與安全令牌服務(wù)（STS）的執(zhí)行。境內(nèi)流離失所者問題的主張有關(guān)身份驗(yàn)證的用戶的信息安全令牌。該信息被稱為權(quán)利要求中，包括用戶的身份，并且還可以包括其他信息，例如角色成員和更細(xì)粒度的訪問權(quán)限。

http://wiki.jikexueyuan.com/project/cloud-design-patterns/images/jim.png" alt="" />

圖1 - 聯(lián)合身份驗(yàn)證概述

該模型通常被稱為基于聲明的訪問控制。應(yīng)用程序和服務(wù)授權(quán)訪問基于包含在令牌中的權(quán)利要求的特征和功能。要求身份驗(yàn)證必須相信國內(nèi)流離失所者的服務(wù)?？蛻舳藨?yīng)用程序的聯(lián)系人執(zhí)行身份驗(yàn)證境內(nèi)流離失所者。如果認(rèn)證成功，則的 IdP 返回包含用于識(shí)別用戶于 STS 的權(quán)利要求書的令牌（注意的 IdP 和 STS 可以是相同的服務(wù)）。在 STS 可以改變和增大中根據(jù)預(yù)定義的規(guī)則，令牌中的權(quán)利要求書，將其返回到客戶端之前。然后，客戶端應(yīng)用程序可以將此令牌傳遞給服務(wù)作為其身份證明。

注意 在某些情況下可能會(huì)有額外的 STS 的信任鏈。例如，在微軟 Azure 的場(chǎng)景描述后，內(nèi)部部署 STS 信任 STS 另一個(gè)是負(fù)責(zé)訪問的身份提供者對(duì)用戶進(jìn)行認(rèn)證。這種方法是在企業(yè)的情況普遍，其中有一個(gè)本地 STS 和目錄。

聯(lián)合身份驗(yàn)證提供了一個(gè)基于標(biāo)準(zhǔn)的解決方案，在不同信任域身份的問題，并且可以支持單點(diǎn)登錄。它正在成為在所有類型的應(yīng)用，特別是云托管的應(yīng)用越來越普遍，因?yàn)樗С稚?，而不需要直接網(wǎng)絡(luò)連接到身份提供單點(diǎn)登錄。用戶不必輸入憑據(jù)為每一種應(yīng)用。這增加了安全性，因?yàn)樗柚沽嗽L問許多不同的應(yīng)用程序所需的憑據(jù)的擴(kuò)散，同時(shí)也隱藏了用戶的憑據(jù)所有，但原來的身份提供者。應(yīng)用程序只看到包含的令牌中的身份驗(yàn)證信息。

聯(lián)合身份也具有重大的優(yōu)點(diǎn)，即人的身份和憑證管理是身份提供者的責(zé)任。應(yīng)用程序或服務(wù)并不需要提供身份管理功能。另外，在企業(yè)環(huán)境中，企業(yè)目錄不需要知道關(guān)于用戶（提供它信任的身份提供者），它去除了管理該目錄中的用戶身份的所有的管理開銷。

問題和注意事項(xiàng)

設(shè)計(jì)實(shí)現(xiàn)聯(lián)合身份驗(yàn)證的應(yīng)用程序時(shí)考慮以下因素：

• 身份驗(yàn)證可以是一個(gè)單點(diǎn)故障。如果您將應(yīng)用程序部署到多個(gè)數(shù)據(jù)中心，考慮部署身份管理機(jī)制，以相同的數(shù)據(jù)中心，以保持應(yīng)用程序的可靠性和可用性。
• 身份驗(yàn)證機(jī)制，可以提供工具來配置基于包含在認(rèn)證令牌的作用索賠的訪問控制。這通常被稱為基于角色的訪問控制（RBAC），并且它可以允許控制權(quán)訪問的功能和資源的更精細(xì)的水平。
• 與企業(yè)目錄，利用社會(huì)身份提供者通常不提供有關(guān)身份驗(yàn)證的用戶以外的電子郵件地址，也許名稱的信息基于聲明的身份。一些社會(huì)身份提供者，如 Microsoft 帳戶，只提供一個(gè)唯一的標(biāo)識(shí)符。應(yīng)用程序通常將需要保持對(duì)注冊(cè)用戶的一些信息，并且能夠匹配該信息，包含在令牌中的權(quán)利要求書的標(biāo)識(shí)符。典型地，這是通過一個(gè)注冊(cè)過程完成的用戶第一次訪問該應(yīng)用程序時(shí)，信息然后被注入到令牌作為每個(gè)認(rèn)證后附加的權(quán)利要求。
• 如果配置為 STS 多個(gè)身份提供者，它必須檢測(cè)其身份提供者，用戶應(yīng)該被重定向到身份驗(yàn)證。這個(gè)過程被稱為主領(lǐng)域發(fā)現(xiàn)。在 STS 可能能夠基于電子郵件地址或用戶名，該用戶提供，該用戶被訪問時(shí)，用戶的 IP 地址范圍，該應(yīng)用程序的一個(gè)子域，或上的 cookie 中存儲(chǔ)的用戶的內(nèi)容自動(dòng)地執(zhí)行此瀏覽器。例如，如果用戶在微軟域，如user@live.com 輸入一個(gè)電子郵件地址，在 STS 將用戶重定向到 Microsoft 帳戶登錄頁面。在隨后的訪問中，STS可以使用 cookie 來表示最后登錄用的 Microsoft 帳戶。如果自動(dòng)發(fā)現(xiàn)無法確定主領(lǐng)域時(shí)，STS 將顯示一個(gè)家庭領(lǐng)域發(fā)現(xiàn)（HRD）頁，其中列出了受信任的身份提供者，用戶必須選擇他們想要使用的人。 何時(shí)使用這個(gè)模式

此模式是非常適合的范圍內(nèi)的情況下，如：

• 在企業(yè)單點(diǎn)登錄。在這種情況下，您需要驗(yàn)證員工被托管在云中的企業(yè)安全邊界以外的企業(yè)應(yīng)用程序，而不需要他們每次訪問應(yīng)用程序時(shí)簽署。用戶體驗(yàn)是一樣的使用本地應(yīng)用程序，他們簽約到公司網(wǎng)絡(luò)時(shí)，最初通過身份驗(yàn)證的時(shí)候，并從此獲得所有相關(guān)的應(yīng)用程序，而無需再次登錄。
• 與多個(gè)合作伙伴聯(lián)合身份。在這種情況下，您需要驗(yàn)證這兩個(gè)企業(yè)的員工和業(yè)務(wù)合作伙伴誰沒有在公司目錄帳戶。這是企業(yè)對(duì)企業(yè)（B2B）的應(yīng)用程序，集成與第三方服務(wù)，并在那里與不同的IT系統(tǒng)公司合并或共享資源的應(yīng)用普遍。
• 在SaaS應(yīng)用聯(lián)合身份。在這種情況下獨(dú)立軟件供應(yīng)商（ISV）提供了一個(gè)即用型服務(wù)，為多個(gè)客戶或租戶。每個(gè)租戶將要使用適當(dāng)?shù)纳矸萏峁┱哌M(jìn)行身份驗(yàn)證。例如，企業(yè)用戶會(huì)希望我們自己的企業(yè)資格證書，而租戶的消費(fèi)者和客戶可能希望使用自己的社會(huì)身份憑證。

這種模式可能不適合于下列情況：

• 應(yīng)用程序的所有用戶都可以通過一個(gè)標(biāo)識(shí)提供者進(jìn)行身份驗(yàn)證，并沒有要求使用任何其他身份提供者進(jìn)行身份驗(yàn)證。這是典型的只使用企業(yè)目錄進(jìn)行身份驗(yàn)證業(yè)務(wù)應(yīng)用，并獲得該目錄可在應(yīng)用程序中直接使用VPN，或（在云中托管的情況下），通過導(dǎo)通之間的虛擬網(wǎng)絡(luò)連接本地目錄和應(yīng)用程序。
• 應(yīng)用程序最初建使用不同的認(rèn)證機(jī)制，或許與自定義用戶存儲(chǔ)，或者不具有處理所用的權(quán)利要求為基礎(chǔ)的技術(shù)的協(xié)商標(biāo)準(zhǔn)的能力。改造基于聲明的身份驗(yàn)證和訪問控制到現(xiàn)有的應(yīng)用程序可能很復(fù)雜，可能不符合成本效益。

例子

組織舉辦了多租戶軟件即在 Azure 中的服務(wù)（SaaS）應(yīng)用程序。該應(yīng)用程序 incudes 一個(gè)網(wǎng)站，租戶可以用它來管理應(yīng)用程序?yàn)樽约旱挠脩?。該?yīng)用程序允許租戶使用由活動(dòng)目錄聯(lián)合服務(wù)（ADFS）產(chǎn)生的，當(dāng)用戶通過該組織自己的 Active Directory 身份驗(yàn)證的聯(lián)合身份訪問租戶的網(wǎng)站。圖2示出了該過程的概述。

http://wiki.jikexueyuan.com/project/cloud-design-patterns/images/jim2.png" alt="" />

圖2 - 用戶如何在大型企業(yè)用戶訪問應(yīng)用程序

在圖 2 所示的場(chǎng)景中，商戶驗(yàn)證自己的身份提供者（步驟1），在這種情況下 ADFS。在成功驗(yàn)證租客，ADFS 發(fā)出的令牌?？蛻舳藶g覽器轉(zhuǎn)發(fā)此令牌至 SaaS 應(yīng)用的聯(lián)合提供者，其信任的租戶的 ADFS 發(fā)出令牌，以便取回的令牌是有效的 SaaS 的聯(lián)合提供者（步驟 2）。如果有必要，在 SaaS 聯(lián)合會(huì)提供商上執(zhí)行令牌中的權(quán)利要求書的權(quán)利要求到該應(yīng)用程序識(shí)別的新令牌返回給客戶機(jī)瀏覽器之前（步驟3）的變換。應(yīng)用程序信任的 SaaS 的聯(lián)合提供者發(fā)出的令牌，并使用在令牌中的權(quán)利要求書申請(qǐng)授權(quán)規(guī)則（步驟 4）。

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