Saml協(xié)議

傳統(tǒng)上，企業(yè)應用程序在公司網(wǎng)絡中部署和運行。為了獲取有關(guān)用戶的信息，如用戶配置文件和組信息，這些應用程序中的許多都是為與公司目錄(如Microsoft Active Directory)集成而構(gòu)建的。更重要的是，通常使用目錄存儲和驗證用戶的憑據(jù)。例如，如果您使用在本地運行的SharePoint和Exchange，則您的登錄憑據(jù)就是您的Active Directory憑據(jù)。

然而，隨著協(xié)作的增加和向基于云的環(huán)境的轉(zhuǎn)變，許多應用程序已經(jīng)超越了公司領(lǐng)域的邊界。聯(lián)合身份驗證是這個問題的解決方案。

想要了解Saml協(xié)議，可以參考對應的官方文檔。

認證服務

大多數(shù)應用程序都有一個用戶存儲(數(shù)據(jù)庫或LDAP)，其中包含用戶配置文件信息和憑據(jù)等。當用戶登錄時，憑據(jù)將根據(jù)此用戶存儲進行驗證。這種簡單方法的優(yōu)勢在于，所有內(nèi)容都在應用程序中進行管理，從而提供了一種對最終用戶進行身份驗證的單一且一致的方法。但是，如果用戶需要訪問多個應用程序，其中每個應用程序都需要不同的憑據(jù)集，那么最終用戶就會遇到問題。首先，除了可能已經(jīng)存在的任何其他公司密碼(例如，他們的AD密碼)之外，用戶還需要記住不同的密碼。用戶現(xiàn)在被迫維護單獨的用戶名和密碼，并且必須處理不同的密碼策略和過期時間。此外，當應用程序用戶繼續(xù)可以訪問本應被撤銷的應用程序時，這種情況還會讓管理員和ISV感到頭疼。

聯(lián)合身份

聯(lián)合身份始于需要支持跨越公司或組織邊界的應用程序訪問。
想象一下，一家果汁公司(JuiceCo)將其產(chǎn)品銷售給一家大型連鎖超市(BigMart)之間的關(guān)系。
作為JuiceCo的一名員工，您需要訪問BigMart提供的應用程序來管理關(guān)系并監(jiān)控供應和銷售。
在這種情況下，BigMart(提供該應用程序)將需要負責用戶身份驗證。
簡單的方法是要求在JuiceCo工作的用戶使用不同的用戶名和密碼。
但是，考慮一下該應用程序需要維護的所有用戶–包括需要訪問該應用程序的所有其他供應商及其用戶。
解決這一問題的一個更好的方法是允許JuiceCo和其他所有供應商共享或聯(lián)合BigMart的身份。
作為JuiceCo的一名員工，您已經(jīng)擁有企業(yè)身份和憑據(jù)。
聯(lián)合身份為連鎖超市(服務提供商)提供了一種安全的方式，通過與其供應商(身份提供商)現(xiàn)有的身份基礎設施集成來外部化身份驗證。

這種用例導致了聯(lián)邦協(xié)議的誕生，例如：Security Assertion Markup Language (SAML) (opens new window).

SAML的規(guī)劃

SAML主要用作基于Web的身份驗證機制，因為它依賴于使用瀏覽器代理來代理身份驗證流。在較高級別，SAML的身份驗證流如下所示：

現(xiàn)在我們準備介紹一些常見的SAML術(shù)語。我們將在稍后討論這些技術(shù)細節(jié)，但在規(guī)劃階段理解高級概念是很重要的。

SP

服務提供商(SP)是提供服務的實體，通常以應用程序的形式提供。

IdP

身份提供者(IdP)是提供身份的實體，包括對用戶進行身份驗證的能力。身份提供者通常還包含用戶配置文件：有關(guān)用戶的其他信息，如名字、姓氏、工作代碼、電話號碼、地址等。根據(jù)應用程序的不同，一些服務提供商可能需要非常簡單的配置文件(用戶名、電子郵件)，而其他服務提供商可能需要更豐富的用戶數(shù)據(jù)集(工作代碼、部門、地址、位置、經(jīng)理等)。

SAML請求

SAML請求，也稱為身份驗證請求，由服務提供商生成以“請求”身份驗證。

SAML響應

SAML響應由身份提供者生成。它包含經(jīng)過身份驗證的用戶的實際斷言。此外，SAML響應可能包含其他信息，例如，用戶配置文件信息和組/角色信息，具體取決于服務提供商可以支持的內(nèi)容。

服務提供商啟動(SP啟動)

登錄描述由服務提供商啟動時的SAML登錄流程。這通常在最終用戶嘗試訪問資源或直接在服務提供商端登錄時觸發(fā)。例如，當瀏覽器嘗試訪問服務提供商端受保護的資源時。

身份提供者啟動(IdP啟動)

身份提供者啟動(IdP啟動)登錄描述由身份提供者啟動的SAML登錄流。在該流程中，身份提供商發(fā)起SAML響應，該響應被重定向到服務提供商以斷言用戶的身份，而不是由來自服務提供商的重定向觸發(fā)SAML流。

需要注意的幾個關(guān)鍵事項

• 服務提供商從不與身份提供商直接交互。
• 瀏覽器充當執(zhí)行所有重定向的代理。
• 服務提供商需要知道要重定向到哪個身份提供商，然后才能知道用戶是誰。
• 在身份提供者返回SAML斷言之前，服務提供者不知道用戶是誰。
• 此流程不一定要從服務提供商開始。
• 身份提供者可以發(fā)起身份驗證流。
• SAML身份驗證流是異步的。
• 服務提供商不知道身份提供商是否會完成整個流程。

因此，服務提供商不維護所生成的任何身份驗證請求的任何狀態(tài)。當服務提供商收到來自身份提供商的響應時，該響應必須包含所有必要的信息。

規(guī)劃核對表

雖然SAML協(xié)議是一個標準，但根據(jù)您的應用程序的性質(zhì)，有不同的方法來實現(xiàn)它。下面是一個核對表，將指導你完成一些關(guān)鍵的考慮事項。

• 了解服務提供商的角色。
• 單一身份識別方案與多個身份識別方案。
• 了解SP發(fā)起的登錄流。
• 暴露SP中的SAML配置。
• 為每個人啟用SAML，而不是為部分用戶。
• 實施“后門”

了解服務提供商的角色

SAML IdP根據(jù)IdP和SP共同同意的配置生成SAML響應。在收到SAML斷言后，SP需要驗證斷言是否來自有效的IdP，然后解析斷言中的必要信息：用戶名、屬性等

要執(zhí)行此操作，SP至少需要以下各項：

• 證書-SP需要從IdP獲取公共證書以驗證簽名。證書存儲在SP端，并在SAML響應到達時使用。
• ACS Endpoint-斷言消費者服務URL-通常簡稱為SP登錄URL。這是由發(fā)布SAML響應的SP提供的終結(jié)點。SP需要將此信息提供給IdP。
• IdP登錄URL-這是發(fā)布SAML請求的IdP端的終結(jié)點，SP需要從IdP獲取此信息。

實現(xiàn)SAML的最簡單方法是利用開源SAML工具包。這些工具包提供了消化傳入SAML響應中的信息所需的邏輯。此外，如果SP需要支持SP發(fā)起的登錄流，工具包還提供生成適當?shù)腟AML身份驗證請求所需的邏輯。

單一身份識別方案與多個身份識別方案

如果您正在構(gòu)建內(nèi)部集成，并且希望啟用SAML以將其與您的公司SAML身份提供程序集成，那么您將考慮僅支持單個IdP。在這種情況下，您的集成只需要處理一組IDP元數(shù)據(jù)(證書、端點等)。

如果您是構(gòu)建企業(yè)SaaS產(chǎn)品的獨立軟件供應商(ISV)，或者您正在為客戶和合作伙伴構(gòu)建面向外部的網(wǎng)站/門戶/社區(qū)，則需要考慮支持多個IdP。這是許多需要與客戶的企業(yè)身份基礎設施集成的SaaS ISV的典型用例。根據(jù)應用程序的體系結(jié)構(gòu)，您需要考慮如何存儲來自每個身份提供者的SAML配置(例如，證書或IdP登錄URL)，以及如何為每個提供者提供必要的SP信息。

一個關(guān)鍵注意事項涉及發(fā)布SAML響應的SP端的ACS URL端點。即使在處理多個IdP時，也可以公開單個端點。對于沒有在URL中定義租用的單實例多租戶應用程序(例如使用子域時)，這可能是一種更簡單的實現(xiàn)方式。但是，您必須依靠SAML響應中的其他信息來確定哪個IdP正在嘗試進行身份驗證(例如，使用IssuerID)。如果您的應用程序是以多租戶方式設置的，并且在URL中包含域信息(例如，使用https://domain1.example.com或https://www.example.com/domain1)，)，則每個子域都有一個ACSURL端點可能是個不錯的選擇，因為URL本身可以標識該域。

了解SP發(fā)起的登錄流

如前所述，IdP發(fā)起的登錄流從IdP開始。由于它從IdP端開始，因此除了用戶嘗試通過身份驗證并訪問SP這一事實外，沒有關(guān)于用戶嘗試在SP端訪問的其他上下文。通常，在用戶通過身份驗證后，瀏覽器將轉(zhuǎn)到SP中的通用登錄頁。

在SP發(fā)起的流中，用戶嘗試直接在SP端訪問受保護的資源，而IdP不知道該嘗試。出現(xiàn)了兩個問題。首先，如果需要對聯(lián)合身份進行身份驗證，則需要識別正確的IdP。使用SP啟動的登錄時，SP最初對身份一無所知。作為開發(fā)人員，您需要弄清楚SP如何確定應該由哪個IdP接收SAML請求。在某些情況下，如果您的應用程序URL包含映射到唯一租戶和IdP的子域信息，則命中的資源鏈接足以識別IdP。如果不是這樣，則可能需要提示最終用戶提供來自最終用戶的其他信息，如用戶ID、電子郵件或公司ID。您需要一些允許SP識別嘗試訪問資源的用戶屬于哪個IdP的內(nèi)容。請記住，您只是提示輸入一個標識符，而不是憑據(jù)。Okta還支持通過LoginHint參數(shù)將標識傳遞給IdP，這樣用戶在重定向到IdP登錄時，就不需要再次輸入該標識。有關(guān)觸發(fā)OKTA將“LoginHint”發(fā)送到IdP的說明，請參閱使用SAML深度鏈接重定向。

SP發(fā)起的登錄流的另一個問題是對深度鏈接的支持。大多數(shù)應用程序都支持深度鏈接。例如，您可能會收到一個指向駐留在內(nèi)容管理系統(tǒng)上的文檔的鏈接。理想情況下，如果您需要在訪問文檔之前進行身份驗證，則希望在身份驗證后立即訪問該文檔。

SAML是一種專門設計的異步協(xié)議。SP發(fā)起的登錄流程從生成SAML身份驗證請求開始，該請求被重定向到IdP。此時，SP不存儲有關(guān)該請求的任何信息。當SAML響應從IdP返回時，SP將不知道任何有關(guān)觸發(fā)身份驗證請求的初始深層鏈接的信息。幸運的是，SAML通過一個名為RelayState的參數(shù)支持這一點。

RelayState

RelayState是一個可以作為SAML請求和SAML響應的一部分包括的HTTP參數(shù)。在SP發(fā)起的登錄流程中，SP可以使用有關(guān)請求的附加信息設置SAML請求中的RelayState參數(shù)。SAML IdP在收到SAML請求后，獲取RelayState值，并在用戶通過身份驗證后將其作為HTTP參數(shù)附加回SAML響應中。這樣，當往返完成時，SP可以使用RelayState信息來獲取有關(guān)初始SAML身份驗證請求的其他上下文。

在深度鏈接的情況下，SP使用深度鏈接值設置SAML請求的RelayState。當SAML響應返回時，SP可以使用RelayState值并將經(jīng)過身份驗證的用戶帶到正確的資源。

暴露SP中的SAML配置

如前所述，SP需要IdP配置來完成SAML設置。雖然許多ISV選擇通過支持和電子郵件來實現(xiàn)這一點，但更好的方法是向客戶的IT管理員顯示自助服務管理員頁面，以啟用SAML。SAML支持IdP端和SP端的元數(shù)據(jù)。在SP側(cè)配置IdP/SP關(guān)系的一種方式是建立接收IdP元數(shù)據(jù)文件的能力和生成供IdP使用的SP元數(shù)據(jù)文件的能力。這是首選的方法。

然而，一些ISV選擇允許直接配置幾個關(guān)鍵的SAML參數(shù)，而不是通過元數(shù)據(jù)文件。典型參數(shù)包括IdP重定向URL(用于SAML請求)、IssuerID、IdP注銷URL。SP還必須允許上載或保存IdP公共證書。

最好使用元數(shù)據(jù)文件，因為它可以處理SAML支持中未來的任何添加/增強，而無需進行用戶界面更改(如果在用戶界面中公開特定的SAML配置參數(shù)，則需要進行這些更改)。

為每個人啟用SAML，而不是為部分用戶

根據(jù)應用程序的性質(zhì)，可能有理由只允許部分用戶啟用SAML。想象一下內(nèi)部員工和外部用戶(如合作伙伴)可以訪問的應用程序。員工可以使用SAML登錄到應用程序，而外部用戶可以使用一組單獨的憑據(jù)。

即使在目的是讓特定租戶的所有用戶都啟用SAML的情況下，在概念驗證、測試和推出期間只啟用部分用戶，以便在對所有用戶啟用之前測試較小的用戶子集的身份驗證，也可能是有用的。

實施“后門”

如果您的應用程序中所有人都打算啟用SAML，這一點尤其重要。有時，SAML配置中可能存在錯誤–或者SAML IdP端點中發(fā)生了一些變化。無論如何，你都不想被完全鎖在門外。讓管理員可以使用后門訪問鎖定的系統(tǒng)變得極其重要。這通常是通過擁有一個“秘密”登錄URL來實現(xiàn)的，該URL在訪問時不會觸發(fā)SAML重定向。通常，管理員使用用戶名和密碼登錄并進行必要的更改以解決問題。

參考資源

• Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0

• Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0

• Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 文章來源地址http://www.zghlxwxcb.cn/news/detail-449040.html

到了這里，關(guān)于【分布式技術(shù)專題】「單點登錄技術(shù)架構(gòu)」一文帶領(lǐng)你好好認識以下Saml協(xié)議的運作機制和流程模式的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！