[[407039]]

【51CTO.com快譯】作為一種在各個(gè)服務(wù)之間交換認(rèn)證和授權(quán)信息的方法，安全斷言標(biāo)記語言(Security Assertion Markup Language，SAML)2.0經(jīng)常被企業(yè)用在構(gòu)建內(nèi)部單點(diǎn)登錄(single sign-on，SSO)方案的過程中，以實(shí)現(xiàn)用戶登錄到統(tǒng)一的身份認(rèn)證服務(wù)處，進(jìn)而授予他們對于其他內(nèi)部服務(wù)子集的訪問權(quán)限。

從安全角度來看，采用SAML/SSO的優(yōu)勢主要體現(xiàn)在如下方面：

• 提供單一的身份來源。當(dāng)有員工加入或離開公司時(shí)，您既不必事無巨細(xì)地去更新每一項(xiàng)內(nèi)部服務(wù)，又不必?fù)?dān)心錯過某個(gè)關(guān)聯(lián)性的重要服務(wù)。
• 強(qiáng)制執(zhí)行一致性的認(rèn)證。可實(shí)施SAML/SSO的方法包括：多因素認(rèn)證和會話持續(xù)時(shí)間等。

下面，我們將重點(diǎn)討論SSO和SAML2.0的認(rèn)證機(jī)制與重要性。

SAML的相關(guān)術(shù)語

主體(Principal)

主體是參與認(rèn)證的用戶。您可以將其視為屏幕后面的實(shí)際訪問者。在下文中，我們將其假設(shè)為John Smith。主體通常會帶有諸如：名字、姓氏、電子郵件地址等附加的元數(shù)據(jù)(metadata)。此類元數(shù)據(jù)往往也被稱為身份信息(identity information)，下面我們將重點(diǎn)闡述其重要性。

身份提供者(Identity Provider)

身份提供者常被簡稱IdP，是提供身份信息和認(rèn)證判斷的源服務(wù)。我們可以將身份提供者視為包含身份信息的數(shù)據(jù)庫。它能夠認(rèn)證主體，并將身份信息返回給服務(wù)提供者(詳見下文)。其中，最常見身份提供者應(yīng)用包括：Auth0、活動目錄聯(lián)合服務(wù)(Active Directory Federation Services，ADFS)和Okta。在實(shí)踐中，人們往往會將組織的所有用戶身份都整合到一個(gè)身份提供者處。

服務(wù)供應(yīng)者(Service Providers)

服務(wù)提供者通常被縮寫為SP，是向主體要求進(jìn)行認(rèn)證和獲取身份信息的服務(wù)。服務(wù)提供者獲取由身份提供者提供的認(rèn)證響應(yīng)，并使用該信息來創(chuàng)建和配置各種會話。也就是說，服務(wù)提供者是某個(gè)應(yīng)用程序，它通過為其用戶提供單點(diǎn)登錄(SSO)機(jī)制，來實(shí)現(xiàn)資源的登錄和訪問。

此類應(yīng)用程序除了知曉主體的名稱或郵件地址以外，還需要請求獲得主體的其他身份信息，以實(shí)現(xiàn)基于角色的訪問控制(role-based access control，RBAC)。典型的服務(wù)提供者應(yīng)用包括：Github、Google Apps、以及Teleport(針對SSH和Kubernetes的一種訪問解決方案)。

流程(Flows)

目前，SAML支持兩種不同類型的流程：由服務(wù)提供者初始化的流程、以及由身份提供者初始化的流程。服務(wù)提供者初始化的流程往往是從服務(wù)提供者開始，被重定向到身份提供者處進(jìn)行認(rèn)證，然后在被重定向回服務(wù)提供者。該流程通常在用戶單擊“使用SSO登錄”按鈕時(shí)被啟動。

綁定(Bindings)

綁定是指在服務(wù)提供者和身份提供者之間傳輸?shù)臄?shù)據(jù)格式。HTTP重定向綁定和HTTP POST綁定是目前最為流行的兩種模式。其中，HTTP重定向綁定使用HTTP重定向和查詢參數(shù)來傳輸數(shù)據(jù);此類綁定通常被用在認(rèn)證的請求中。HTTP POST綁定則使用各種HTTP POST表單來傳輸數(shù)據(jù)，此類綁定通常被用在認(rèn)證的響應(yīng)中。

斷言(Assertions)

斷言是身份提供者對主體所做的聲明，包括：主體的電子郵件地址、與之關(guān)聯(lián)的組或角色等。服務(wù)提供者使用斷言為主體創(chuàng)建和配置會話。也就是說，斷言定義了身份提供者在向服務(wù)提供者傳送的過程中，包含了主體具有哪些身份信息。

SAML的登錄流

為了說明SAML登錄的工作原理，我們將在如下示例中使用Teleport作為服務(wù)提供者，使用Auth0作為身份提供者。SAML登錄的基本流程，如下圖所示：

1. 用戶單擊“通過Auth0登錄”按鈕，選擇使用SAML登錄，而不是使用Teleport的內(nèi)置用戶數(shù)據(jù)庫。Teleport會將用戶重定向到Auth0處。在此，用戶便是SAML中的主體。

2. Auth0要求用戶提供他們的用戶名(或電子郵件)、密碼、以及認(rèn)證令牌作為第二認(rèn)證因素(2FA)。

3. 如果提供的信息正確，Auth0將獲取主體的身份信息，并將其作為斷言返回給Teleport。

4. Teleport會從Auth0處接收到身份信息，進(jìn)而創(chuàng)建用戶會話。

配置

身份提供者往往擁有自己獨(dú)特的配置方法。下面是身份提供者與服務(wù)提供者在協(xié)作時(shí)需要的最少配置集：

• 斷言消費(fèi)者服務(wù)(Assertion Consumer Service，ACS)的URL是服務(wù)提供者的端點(diǎn)，身份提供者將其認(rèn)證的響應(yīng)重定向到該端點(diǎn)處。由于它將被用于傳輸個(gè)人身份信息(Personally Identifiable Information，PII)，因此該端點(diǎn)應(yīng)當(dāng)被配置為HTTPS類型。
• 生成并上傳用于簽發(fā)認(rèn)證請求的簽名密鑰(詳見下文)。
• 對斷言中所包含的有關(guān)主體信息的來源和格式進(jìn)行配置。身份提供者至少需要發(fā)送NameID、以及組成員等信息。

服務(wù)提供者的配置通常比較簡單，并且可以通過解析身份提供者所提供的元數(shù)據(jù)，來自動完成配置。如下Django(譯者注：一個(gè)開放源代碼的Web應(yīng)用框架，由Python編寫而成。)代碼段展示了簡單的身份提供者元數(shù)據(jù)的XML。其中，最重要的標(biāo)簽當(dāng)屬SingleSignOnService和KeyDescriptor。具體而言，SingleSignOnService標(biāo)簽定義了有待發(fā)送認(rèn)證請求的綁定和端點(diǎn)，而KeyDescriptor標(biāo)簽則包含了有待認(rèn)證響應(yīng)的身份提供者的公鑰。

<md:EntityDescriptor> 
  <md:IDPSSODescriptor> 
    <md:KeyDescriptor use="signing"> 
      <ds:KeyInfo> 
        <ds:X509Data> 
          <ds:X509Certificate> 
            MIICMjCCAZugAwIBAgIBADANBgkqhkiG9w0BAQ0FADA2MQswCQYDVQQGEwJ1czEL 
            MAkGA1UECAwCQ0ExDDAKBgNVBAoMA2lkcDEMMAoGA1UEAwwDaWRwMB4XDTE5MDQy 
            NjE4NTIxOFoXDTIwMDQyNTE4NTIxOFowNjELMAkGA1UEBhMCdXMxCzAJBgNVBAgM 
            AkNBMQwwCgYDVQQKDANpZHAxDDAKBgNVBAMMA2lkcDCBnzANBgkqhkiG9w0BAQEF 
            AAOBjQAwgYkCgYEA1mKmlbr/SiHOhgdROpYeze96mw0WbO+BdJYDceeuNkaw0zOU 
            CKZI6TNgrNsqEnLOyWYy5ywA9XA6Ni2qQTuKqapsMT3I1s9DMUg2ln7tTzNdhE02 
            fY4GVjiCw7i9YJ+cgcMZh8qL0yoilrLpRLzLrRC6rApqYfEwn+5FPKtTt7cCAwEA 
            AaNQME4wHQYDVR0OBBYEFNvFMRtHJ4D327dbRbxhWceXnwd0MB8GA1UdIwQYMBaA 
            FNvFMRtHJ4D327dbRbxhWceXnwd0MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEN 
            BQADgYEAX0I5zpGqI7vzzs8CDyokux1JZzfu+O3P5GfOwUaIG9y01FzxgbL2MRKQ 
            oTXMAed97Q6vHA5cffvteu/rPcerpGmFj5h3wv5u+D0ch5s/Mk/Ug6S+x6k3CC+P 
            kHimi6OEslFecDMhghUtPJAmhOGnTRwLr7hVeJXBHXWCTXA7aGE= 
          </ds:X509Certificate> 
        </ds:X509Data> 
      </ds:KeyInfo> 
    </md:KeyDescriptor> 
    <md:NameIDFormat> 
       urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress 
    </md:NameIDFormat> 
    <md:SingleSignOnService 
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
      Location="https://idp.example.com/saml"/> 
    <md:SingleSignOnService  
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" 
      Location="https://idp.example.com/saml"/> 
  </md:IDPSSODescriptor> 
</md:EntityDescriptor> 

認(rèn)證請求

在主體登錄的過程中，服務(wù)提供者會創(chuàng)建一個(gè)AuthnRequest的XML文檔，通過對其序列化(可采用base64、壓縮和URL編碼)，將其作為查詢參數(shù)添加到URL中，并將主體的瀏覽器重定向到身份提供者的登錄頁面處。服務(wù)提供者會請求身份提供者以HTTPS的方式，代為執(zhí)行認(rèn)證。如下URL示例便是由HTTP重定向使用綁定AuthnRequest發(fā)送的：

https://idp.example.com/saml?SAMLRequest=nFdpk6JK0%2F0rHc7... 

如下Django代碼段展示了由AuthnRequest編碼的SAMLRequest簡化參數(shù)：

<md:IDPSSODescriptor> 
   <md:KeyDescriptor use=&quot;signing&quot;> 
     <ds:KeyInfo> 
       <ds:X509Data> 
         <ds:X509Certificate> 
           MIICMjCCAZugAwIBAgIBADANBgkqhkiG9w0BAQ0FADA2MQswCQYDVQQGEwJ1czEL 
           MAkGA1UECAwCQ0ExDDAKBgNVBAoMA2lkcDEMMAoGA1UEAwwDaWRwMB4XDTE5MDQy 
           NjE4NTIxOFoXDTIwMDQyNTE4NTIxOFowNjELMAkGA1UEBhMCdXMxCzAJBgNVBAgM 
           AkNBMQwwCgYDVQQKDANpZHAxDDAKBgNVBAMMA2lkcDCBnzANBgkqhkiG9w0BAQEF 
           AAOBjQAwgYkCgYEA1mKmlbr/SiHOhgdROpYeze96mw0WbO+BdJYDceeuNkaw0zOU 
           CKZI6TNgrNsqEnLOyWYy5ywA9XA6Ni2qQTuKqapsMT3I1s9DMUg2ln7tTzNdhE02 
           fY4GVjiCw7i9YJ+cgcMZh8qL0yoilrLpRLzLrRC6rApqYfEwn+5FPKtTt7cCAwEA 
           AaNQME4wHQYDVR0OBBYEFNvFMRtHJ4D327dbRbxhWceXnwd0MB8GA1UdIwQYMBaA 
           FNvFMRtHJ4D327dbRbxhWceXnwd0MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEN 
           BQADgYEAX0I5zpGqI7vzzs8CDyokux1JZzfu+O3P5GfOwUaIG9y01FzxgbL2MRKQ 
           oTXMAed97Q6vHA5cffvteu/rPcerpGmFj5h3wv5u+D0ch5s/Mk/Ug6S+x6k3CC+P 
           kHimi6OEslFecDMhghUtPJAmhOGnTRwLr7hVeJXBHXWCTXA7aGE= 
         </ds:X509Certificate> 
       </ds:X509Data> 
     </ds:KeyInfo> 
   </md:KeyDescriptor> 
   <md:NameIDFormat> 
      urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress 
   </md:NameIDFormat> 
   <md:SingleSignOnService 
     Binding=&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&quot; 
     Location=&quot;https://idp.example.com/saml&quot;></md:SingleSignOnService> 
   <md:SingleSignOnService  
     Binding=&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect&quot; 
     Location=&quot;https://idp.example.com/saml&quot;></md:SingleSignOnService> 
 </md:IDPSSODescriptor> 
/md:EntityDescriptor>" 

服務(wù)提供者會生成一個(gè)較大的安全隨機(jī)數(shù)，并將其插入AuthnRequest標(biāo)簽中的ID字段。該值通常會被存儲在本地?cái)?shù)據(jù)庫中，可用于將請求與來自身份提供者的響應(yīng)進(jìn)行比對，以防止惡意的第三方在不知道ID的情況下，發(fā)送未經(jīng)請求的響應(yīng)。

同時(shí)，為了防止重復(fù)使用已過期的AuthnRequests，身份提供者需要存儲和跟蹤那些已被使用過的ID值?？梢?，如果沒有時(shí)間限制的話，這將會導(dǎo)致身份提供者所需的存儲量不斷攀升。而IssueInstant恰好可以為請求產(chǎn)生有效的窗口。

服務(wù)提供者負(fù)責(zé)簽發(fā)AuthnRequest。而在SAML的簽名方案中包含了：簽名、用于簽發(fā)請求的密鑰、以及有關(guān)如何在Signature標(biāo)簽中計(jì)算簽名的所有信息。因此身份提供者不僅應(yīng)該認(rèn)證用于簽發(fā)請求的密鑰，還應(yīng)該認(rèn)證該密鑰是否與在配置時(shí)上傳的密鑰為同一個(gè)(請參閱上一節(jié))。如果密鑰或簽名值不匹配、或丟失的話，身份提供者就會判定請求為非法，并直接拒絕之。實(shí)際上，SAML會使用XML數(shù)字簽名來簽發(fā)請求的內(nèi)容，其本身是一個(gè)龐大而復(fù)雜的主題。您可以通過鏈接--https://www.di-mgt.com.au/xmldsig.html，來進(jìn)一步了解如何使用XMLDSIG去簽發(fā)XML文檔。

認(rèn)證響應(yīng)

接著，讓我們回到認(rèn)證的流程。如果主體輸入了正確的登錄憑據(jù)，身份提供者將會對服務(wù)提供者的ACS URL(例如，在本示例中為--https://sp.example.com/saml/acs)執(zhí)行“302重定向”。其正文中包含了認(rèn)證的響應(yīng)。如下的Django代碼段是一個(gè)簡化版的SAMLResponse：

saml2p: Response 
Destination=\"https://sp.example.com/saml/acs\" 
ID=\"id35287812421219341967493380\" 
InResponseTo=\"bcf0b634-67b4-4dc9-a436-4e5cfcfb80e2\" 
IssueInstant=\"2019-04-18T18:51:46.729Z\"> 
<ds:Signature> 
<ds:SignedInfo> 
<ds:CanonicalizationMethod 
Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\" /> 
<ds:SignatureMethod 
Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\" /> 
<ds:Reference URI=\"#id35287812421219341967493380\"> 
<ds:Transforms> 
<ds:Transform 
Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\" /> 
<ds:Transform 
Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\",/> 
</ds:Transforms> 
<ds:DigestMethod 
Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\" /> 
<ds:DigestValue> 
tyLUm4r2isgN+L6sRcqDSEa1Zb7WQbQJG6PpLcf3Mrc= 
</ds:DigestValue> 
</ds:Reference> 
</ds:SignedInfo> 
<ds:SignatureValue> 
XjqbZty/QkqTnMV8YsS2XJ3qgVLPGNC67o/WmzkzoAyl3SBOCGllV4UdijkTjhgykQP7MVXyCql0 
eRtIMJ++rbi3OxCSc0LN67znuTS7cAfcOQzYBtYX2R9w3GlEAO0kZusWYlP3cu/ObmQZUQ7CSgr4 
DRXsVWRhSmmpxHl6klC6c10eWiIlK7Ccpvvvb2hlwl8anyuO/CcKH0n/Rb9vHWtsAlqKXZ8G4X6M 
77AfRFC7yDWk+8B784109phQxcxoDYjuQNO5IkiRE6J2LnkmuaPoKVyTtpP2JYLiYMSBu8laDsnZ 
I/ewOtBwr16j9oOJpgHPQufQJfvcg+rPEwkptg== 
</ds:SignatureValue> 
<ds:KeyInfo> 
<ds:X509Data> 
<ds:X509Certificate> 
MIICMjCCAZugAwIBAgIBADANBgkqhkiG9w0BAQ0FADA2MQswCQYDVQQGEwJ1czEL 
MAkGA1UECAwCQ0ExDDAKBgNVBAoMA2lkcDEMMAoGA1UEAwwDaWRwMB4XDTE5MDQy 
NjE4NTIxOFoXDTIwMDQyNTE4NTIxOFowNjELMAkGA1UEBhMCdXMxCzAJBgNVBAgM 
AkNBMQwwCgYDVQQKDANpZHAxDDAKBgNVBAMMA2lkcDCBnzANBgkqhkiG9w0BAQEF 
AAOBjQAwgYkCgYEA1mKmlbr/SiHOhgdROpYeze96mw0WbO+BdJYDceeuNkaw0zOU 
CKZI6TNgrNsqEnLOyWYy5ywA9XA6Ni2qQTuKqapsMT3I1s9DMUg2ln7tTzNdhE02 
fY4GVjiCw7i9YJ+cgcMZh8qL0yoilrLpRLzLrRC6rApqYfEwn+5FPKtTt7cCAwEA 
AaNQME4wHQYDVR0OBBYEFNvFMRtHJ4D327dbRbxhWceXnwd0MB8GA1UdIwQYMBaA 
FNvFMRtHJ4D327dbRbxhWceXnwd0MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEN 
BQADgYEAX0I5zpGqI7vzzs8CDyokux1JZzfu+O3P5GfOwUaIG9y01FzxgbL2MRKQ 
oTXMAed97Q6vHA5cffvteu/rPcerpGmFj5h3wv5u+D0ch5s/Mk/Ug6S+x6k3CC+P 
kHimi6OEslFecDMhghUtPJAmhOGnTRwLr7hVeJXBHXWCTXA7aGE= 
</ds:X509Certificate> 
</ds:X509Data> 
</ds:KeyInfo> 
</ds:Signature> 
<saml2p:Status> 
<saml2p:StatusCode 
Value=\"urn:oasis:names:tc:SAML:2.0:status:Success\" /> 
</saml2p:Status> 
<saml2:Assertion 
ID=\"id35287812421980111258419174\" 
IssueInstant=\"2019-04-18T18:51:46.729Z\"> 
<ds:Signature> 
<ds:SignedInfo> 
<ds:CanonicalizationMethod 
Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\" /> 
<ds:SignatureMethod 
Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\" /> 
<ds:Reference URI=\"#id35287812421980111258419174\"> 
<ds:Transforms> 
<ds:Transform 
Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\" /> 
<ds:Transform 
Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\"/> 
</ds:Transforms> 
<ds:DigestMethod 
Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\" /> 
<ds:DigestValue> 
VKPsgTPABNq1SvInCMXd04LZCvRYMnJzEeT5oIs70hw= 
</ds:DigestValue> 
</ds:Reference> 
</ds:SignedInfo> 
<ds:SignatureValue> 
gsUzQuivXX378HkYNI+plBkp1BvPUNmJD+kh825nHwIBNd019IxffVmOfRAQAkZhT6rqxWhO5/Yc 
JGR5J0qjJVmrRrJ/ipT4VfuJsbn346nEFSMU15D0h3UHrvl651C+NStyXsi8Q8502Qe0ChHOtEXM 
rw9HWPwYtJX0rlpNEzLUnEQPvJ4pd3bz9SIl/YXMNTxE7NCDOxPXKtA4namkkweilxTCynM6A1kn 
6gEWaXhLMwLLAV6kOtivdVksBPzR9BeZ7RPpXeqt0qN62L4NaHq3OsdjgtQr9sllssD1fEek1eU4 
giCzPgb1+LjvD9dpFH5pcLt9YlwHyYgEBBLOQg== 
</ds:SignatureValue> 
<ds:KeyInfo> 
<ds:X509Data> 
<ds:X509Certificate> 
MIICMjCCAZugAwIBAgIBADANBgkqhkiG9w0BAQ0FADA2MQswCQYDVQQGEwJ1czEL 
MAkGA1UECAwCQ0ExDDAKBgNVBAoMA2lkcDEMMAoGA1UEAwwDaWRwMB4XDTE5MDQy 
NjE4NTIxOFoXDTIwMDQyNTE4NTIxOFowNjELMAkGA1UEBhMCdXMxCzAJBgNVBAgM 
AkNBMQwwCgYDVQQKDANpZHAxDDAKBgNVBAMMA2lkcDCBnzANBgkqhkiG9w0BAQEF 
AAOBjQAwgYkCgYEA1mKmlbr/SiHOhgdROpYeze96mw0WbO+BdJYDceeuNkaw0zOU 
CKZI6TNgrNsqEnLOyWYy5ywA9XA6Ni2qQTuKqapsMT3I1s9DMUg2ln7tTzNdhE02 
fY4GVjiCw7i9YJ+cgcMZh8qL0yoilrLpRLzLrRC6rApqYfEwn+5FPKtTt7cCAwEA 
AaNQME4wHQYDVR0OBBYEFNvFMRtHJ4D327dbRbxhWceXnwd0MB8GA1UdIwQYMBaA 
FNvFMRtHJ4D327dbRbxhWceXnwd0MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEN 
BQADgYEAX0I5zpGqI7vzzs8CDyokux1JZzfu+O3P5GfOwUaIG9y01FzxgbL2MRKQ 
oTXMAed97Q6vHA5cffvteu/rPcerpGmFj5h3wv5u+D0ch5s/Mk/Ug6S+x6k3CC+P 
kHimi6OEslFecDMhghUtPJAmhOGnTRwLr7hVeJXBHXWCTXA7aGE= 
</ds:X509Certificate> 
</ds:X509Data> 
</ds:KeyInfo> 
</ds:Signature> 
<saml2:Subject> 
<saml2:NameID> 
jsmith@example.com 
</saml2:NameID> 
<saml2:SubjectConfirmation> 
<saml2:SubjectConfirmationData 
InResponseTo=\"bcf0b634-67b4-4dc9-a436-4e5cfcfb80e2\" 
NotOnOrAfter=\"2019-04-18T18:56:46.730Z\" 
Recipient=\"https://sp.example.com/saml/acs\" /> 
</saml2:SubjectConfirmation> 
</saml2:Subject> 
<saml2:Conditions 
NotBefore=\"2019-04-18T18:46:46.730Z\" 
NotOnOrAfter=\"2019-04-18T18:56:46.730Z\" 
xmlns:saml2=\"urn:oasis:names:tc:SAML:2.0:assertion\"> 
</saml2:Conditions> 
<saml2:AuthnStatement 
AuthnInstant=\"2019-04-18T18:51:46.729Z\" 
SessionIndex=\"bcf0b634-67b4-4dc9-a436-4e5cfcfb80e2\"> 
</saml2:AuthnStatement> 
<saml2:AttributeStatement> 
<saml2:Attribute 
Name=\"logins\"> 
<saml2:AttributeValue> 
root 
</saml2:AttributeValue> 
<saml2:AttributeValue> 
jsmith 
</saml2:AttributeValue> 
</saml2:Attribute> 
<saml2:Attribute 
Name=\"groups\"> 
<saml2:AttributeValue> 
admins 
</saml2:AttributeValue> 
<saml2:AttributeValue> 
developers 
</saml2:AttributeValue> 
</saml2:Attribute> 
</saml2:AttributeStatement> 
</saml2:Assertion> 
</saml2p:Response> 

當(dāng)服務(wù)提供者接收到認(rèn)證響應(yīng)時(shí)，應(yīng)當(dāng)檢查InResponseTo屬性所引用的AuthnRequest的ID，是否由真實(shí)的服務(wù)提供者所發(fā)送。同時(shí)，IssueInstant屬性可以用來確定響應(yīng)的有效性窗口的范圍。

由于認(rèn)證響應(yīng)被傳遞到ACS URL處時(shí)并不會執(zhí)行客戶端認(rèn)證，因此這就是為什么我們需要Signature去認(rèn)證響應(yīng)中的客戶端，是否為真實(shí)的身份提供者的原因。這與webhooks(一種自動化部署)的概念非常相似：那些被用于認(rèn)證客戶端的信息(在webhooks中通常是指API密鑰)需要提前在帶外完成交換。

對應(yīng)的響應(yīng)中有著四個(gè)新的標(biāo)簽：Status、Subject、Conditions、以及AttributeStatement。其中：

• Status包含了認(rèn)證是否成功的結(jié)果。
• Subject標(biāo)識了通過認(rèn)證的主體。例如在上例中，NameID標(biāo)簽就包含了認(rèn)證主體的電子郵件地址：jsmith@example.com。
• Conditions定義了斷言的限制。例如，NotBefore和NotOnOrAfter屬性定義了斷言有效期的持續(xù)時(shí)長。這樣可以防止惡意行為者通過記錄有效的認(rèn)證響應(yīng)，進(jìn)行重放(replaying)攻擊。
• AttributeStatement包含了身份提供者針對主體所做出的斷言。如前所述，斷言通常會包含諸如：組織內(nèi)部的組成員身份、受允許的登錄、以及有關(guān)主體的其他識別信息。在上例中，該主體屬于admins和developers組，并被允許以root和jsmith身份登錄。

可見，我們需要記住的是：主體的斷言只是在識別信息時(shí)的一個(gè)快照，如果提供長期存在(long-lived)的斷言、或會話，就會存在安全隱患。因此，我們需要讓斷言和會話保持合理且短暫(short-lived)，以及通過強(qiáng)制性的重新認(rèn)證，來確保身份提供者對主體所做出的斷言的有效性。

小結(jié)

綜上所述，服務(wù)提供者會根據(jù)判斷的結(jié)果，來提供響應(yīng)。只有成功的響應(yīng)才會在內(nèi)部服務(wù)中創(chuàng)建會話，提供單一的身份源，以及實(shí)現(xiàn)橫跨內(nèi)部服務(wù)的一致性認(rèn)證。為此，服務(wù)提供者通常需要知道主體所屬的用戶組，并據(jù)此實(shí)施基于角色的訪問控制策略。例如，只有來自“SSH”組的用戶，才能夠訪問生產(chǎn)環(huán)境;而其他組的用戶，則需要根據(jù)不同的策略，去訪問Kubernetes集群、或CI/CD管道。

總的說來，SAML認(rèn)證解決了如下三個(gè)重要問題：

• SAML顯著改善了用戶的體驗(yàn)。用戶只需要記住他們常用的單一身份憑據(jù)，而不必針對不同的應(yīng)用，使用不同的用戶名和密碼。
• SAML允許應(yīng)用程序開發(fā)人員將身份管理和認(rèn)證實(shí)施，外包給外部的提供者，而無需自行實(shí)現(xiàn)。
• 最重要的是，SAML顯著降低了組織內(nèi)針對訪問管理的運(yùn)營開銷。如果有員工離開或轉(zhuǎn)移到其他團(tuán)隊(duì)，他們的訪問權(quán)限將會在連接到身份提供者所對應(yīng)的應(yīng)用時(shí)，自動被撤銷或降級。

原文標(biāo)題：How SAML 2.0 Authentication Works and Why It Matters，作者：Ev Kontsevoy

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】