將驗證委派給外部識別提供者。 這可簡化開發、將使用者管理的需求降到最低，並改善應用程式的用戶體驗。
內容和問題
使用者通常需要使用由他們擁有業務關係的不同組織所提供的多個應用程式並裝載。 這些使用者可能需要針對每個使用者使用特定的 （和不同） 認證。 這可以：
造成脫離的用戶體驗。 當用戶擁有許多不同的認證時，通常會忘記登入認證。
公開安全性弱點。 當用戶離開公司時，必須立即取消布建帳戶。 在大型組織中很容易忽略這一點。
使用戶管理複雜化。 管理員 istrators 必須管理所有使用者的認證，並執行其他工作，例如提供密碼提醒。
使用者通常偏好針對所有這些應用程式使用相同的認證。
解決方案
實作可使用同盟身分識別的驗證機制。 將使用者驗證與應用程式程式代碼分開，並將驗證委派給受信任的識別提供者。 這可簡化開發和允許使用者使用更廣泛的識別提供者 （IdP） 進行驗證，同時將系統管理額外負荷降至最低。 它也可讓您清楚將驗證與授權分離。
受信任的識別提供者包括公司目錄、內部部署同盟服務、商務夥伴所提供的其他安全性令牌服務（STS），或可驗證擁有 Microsoft、Google、Yahoo！或 Facebook 帳戶的使用者的社會識別提供者。
此圖說明當用戶端應用程式需要存取需要驗證的服務時，同盟身分識別模式。 驗證是由與 STS 搭配運作的 IdP 所執行。 IdP 會發出安全性令牌，以提供已驗證使用者的相關信息。 這項信息稱為宣告，包括使用者的身分識別，也可能包含其他資訊，例如角色成員資格和更細微的訪問許可權。
此模型通常稱為宣告型訪問控制。 應用程式和服務會根據令牌中包含的宣告，授權存取特性與功能。 需要驗證的服務必須信任 IdP。 用戶端應用程式會連絡執行驗證的IdP。 如果驗證成功，IdP 會傳回令牌，其中包含識別使用者給 STS 的宣告（請注意，IdP 和 STS 可以是相同的服務）。 STS 可以根據預先定義的規則，轉換和增強令牌中的宣告，然後再將它傳回用戶端。 用戶端應用程式接著可以將此令牌傳遞至服務，作為其身分識別的證明。
信任鏈結中可能會有額外的安全性令牌服務。 例如，在稍後所述的案例中，內部部署 STS 會信任另一個負責存取身分識別提供者來驗證使用者的 STS。 在有內部部署 STS 和目錄的企業案例中，這種方法很常見。
同盟驗證提供標準型解決方案，可解決跨不同網域信任身分識別的問題，並可支援單一登錄。 這種類型的驗證在所有類型的應用程式中變得越來越常見，尤其是雲端裝載的應用程式，因為它支援單一登錄，而不需要直接網路連線到識別提供者。 使用者不需要輸入每個應用程式的認證。 這會增加安全性，因為它會防止建立存取許多不同的應用程式所需的認證，而且也會隱藏使用者除了原始識別提供者外的所有認證。 應用程式只會看到令牌中包含的已驗證身分識別資訊。
同盟身分識別也有管理身分識別和認證的主要優點，就是身分識別提供者的責任。 應用程式或服務不需要提供身分識別管理功能。 此外，在公司案例中，如果公司目錄信任識別提供者，則不需要知道使用者。 這會移除管理目錄中使用者身分識別的所有系統管理額外負荷。
問題和考慮
設計實作同盟驗證的應用程式時，請考慮下列事項：
驗證可以是單一失敗點。 如果您將應用程式部署至多個資料中心，請考慮將身分識別管理機制部署到相同的數據中心，以維護應用程式可靠性和可用性。
驗證工具可讓您根據驗證令牌中包含的角色宣告來設定訪問控制。 這通常稱為角色型訪問控制 （RBAC），而且可以更細微地控制對功能和資源的存取。
不同於公司目錄，使用社交識別提供者的宣告型驗證通常不會提供電子郵件位址以外的已驗證使用者相關信息，也可能提供名稱。 某些社交識別提供者，例如 Microsoft 帳戶，只提供唯一標識碼。 應用程式通常需要維護已註冊使用者的一些資訊，而且能夠將這項資訊與令牌中宣告中包含的標識符相符。 這通常是在使用者第一次存取應用程式時透過註冊來完成，然後在每次驗證之後，將資訊插入令牌作為其他宣告。
如果為 STS 設定了多個識別提供者，STS 必須判斷用戶應該重新導向至哪個識別提供者以進行驗證。 此程式稱為主領域探索。 STS 可以根據使用者提供的電子郵件地址或使用者名稱、使用者正在存取的應用程式子域、使用者的IP位址範圍，或儲存在使用者瀏覽器中的Cookie內容，自動執行此動作。 例如，如果使用者在 Microsoft 網域中輸入電子郵件位址，例如 user@live.com，STS 會將使用者重新導向至 Microsoft 帳戶登入頁面。 稍後造訪時，STS 可以使用 Cookie 來指出最後一次登入是使用 Microsoft 帳戶。 如果自動探索無法判斷主領域，STS 會顯示主領域探索頁面，其中列出受信任的識別提供者，而且用戶必須選取他們要使用的網域。
使用此模式的時機
此模式適用於下列案例：
企業中的單一登錄。 在此案例中，您需要針對裝載於公司安全性界限外部雲端的公司應用程式驗證員工，而不需要他們每次造訪應用程式時登入。 用戶體驗與在登入公司網路時使用內部部署應用程式時相同，然後從此即可存取所有相關應用程式，而不需要再次登入。
與多個合作夥伴的同盟身分識別。 在此案例中，您必須驗證沒有公司目錄中帳戶的公司員工和商務合作夥伴。 這在企業對企業應用程式中很常見、與第三方服務整合的應用程式，以及具有不同IT系統的公司已合併或共用資源的位置。
SaaS 應用程式中的同盟身分識別。 在此案例中，獨立軟體廠商為多個用戶端或租使用者提供現成可用的服務。 每個租用戶都會使用適當的識別提供者進行驗證。 例如，商務使用者會使用其公司認證，而租使用者的取用者和用戶端會使用其社交身分識別認證。
在下列情況下，此模式可能沒有用處：
應用程式的所有使用者都可以由一個識別提供者進行驗證，而且不需要使用任何其他識別提供者進行驗證。 這通常是在商務應用程式中，透過內部部署目錄與應用程式之間的虛擬網路連線，使用 VPN 或 （在雲端裝載案例中）來驗證公司目錄（可在應用程式記憶體取）。
應用程式最初是使用不同的驗證機制來建置，或許是搭配自定義使用者存放區，或沒有能力處理宣告型技術所使用的交涉標準。 將宣告型驗證和訪問控制改造成現有的應用程式可能相當複雜，而且可能不符合成本效益。
工作負載設計
架構設計人員應該評估如何在其工作負載的設計中使用同盟身分識別模式，以解決 Azure 良好架構架構支柱中涵蓋的目標和原則。 例如：
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 可靠性設計決策可協助工作負載復原到故障，並確保它會在發生失敗后復原到完全正常運作的狀態。 | 卸除使用者管理和驗證會將這些元件的可靠性轉移至識別提供者，這通常具有高 SLO。 此外，在工作負載災害復原期間，驗證元件可能不需要在工作負載復原方案中解決。 - RE：02 重要流程 - RE：09 災害復原 |
| 安全性 設計決策有助於確保 工作負載數據和系統的機密性、 完整性和 可用性 。 | 藉由外部化使用者管理和驗證，您可以取得身分識別型威脅偵測和預防的演進功能，而不需要在您的工作負載中實作這些功能。 而外部識別提供者則使用新式互通的驗證通訊協定。 - SE：02 安全開發生命週期 - SE：10 監視和威脅偵測 |
| 效能效率 可透過調整、數據、程式代碼的優化，有效率地協助您的工作負載 符合需求 。 | 當您卸除使用者管理和驗證時，您可以將應用程式資源投入其他優先順序。 - PE：03 選取服務 |
如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。
範例
組織在 Microsoft Azure 中裝載多租使用者軟體即服務 （SaaS） 應用程式。 應用程式包含一個網站，租用戶可用來為自己的使用者管理應用程式。 當組織自己的 Active Directory 驗證使用者時，應用程式可讓租使用者使用由 Active Directory 同盟服務 （AD FS） 產生的同盟身分識別來存取網站。
此圖顯示租使用者如何向自己的識別提供者進行驗證（步驟 1），在此案例中為 AD FS。 成功驗證租用戶之後，AD FS 會發出令牌。 用戶端瀏覽器會將此令牌轉送至 SaaS 應用程式的同盟提供者，此提供者信任租使用者 AD FS 所簽發的令牌，以便取得對 SaaS 同盟提供者有效的令牌（步驟 2）。 如有必要，SaaS 同盟提供者會在令牌中的宣告上執行轉換，以將應用程式辨識的宣告（步驟 3）傳回至用戶端瀏覽器。 應用程式會信任 SaaS 同盟提供者所簽發的令牌，並使用令牌中的宣告來套用授權規則 （步驟 4）。
租使用者不需要記住個別的認證來存取應用程式，而租使用者公司的系統管理員可以在自己的AD FS 中設定可存取應用程式的使用者清單。