自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

安全斷言標記語言SAML2.0的認證機制與重要性

譯文
作者：陳峻
開發(fā) 前端
安全斷言標記語言(SAML)2.0是目前被廣泛使用的開放標準之一，可被用于多方之間的認證和授權。本文將和您討論其認證機制與重要性。

[[407039]]

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

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

  • 提供單一的身份來源。當有員工加入或離開公司時，您既不必事無巨細地去更新每一項內部服務，又不必擔心錯過某個關聯(lián)性的重要服務。
  • 強制執(zhí)行一致性的認證?？蓪嵤㏒AML/SSO的方法包括：多因素認證和會話持續(xù)時間等。

下面，我們將重點討論SSO和SAML2.0的認證機制與重要性。

SAML的相關術語

主體(Principal)

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

身份提供者(Identity Provider)

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

服務供應者(Service Providers)

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

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

流程(Flows)

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

綁定(Bindings)

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

斷言(Assertions)

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

SAML的登錄流

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

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

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

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

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

配置

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

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

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

  1. <md:EntityDescriptor> 
  2.   <md:IDPSSODescriptor> 
  3.     <md:KeyDescriptor use="signing"> 
  4.       <ds:KeyInfo> 
  5.         <ds:X509Data> 
  6.           <ds:X509Certificate> 
  7.             MIICMjCCAZugAwIBAgIBADANBgkqhkiG9w0BAQ0FADA2MQswCQYDVQQGEwJ1czEL 
  8.             MAkGA1UECAwCQ0ExDDAKBgNVBAoMA2lkcDEMMAoGA1UEAwwDaWRwMB4XDTE5MDQy 
  9.             NjE4NTIxOFoXDTIwMDQyNTE4NTIxOFowNjELMAkGA1UEBhMCdXMxCzAJBgNVBAgM 
  10.             AkNBMQwwCgYDVQQKDANpZHAxDDAKBgNVBAMMA2lkcDCBnzANBgkqhkiG9w0BAQEF 
  11.             AAOBjQAwgYkCgYEA1mKmlbr/SiHOhgdROpYeze96mw0WbO+BdJYDceeuNkaw0zOU 
  12.             CKZI6TNgrNsqEnLOyWYy5ywA9XA6Ni2qQTuKqapsMT3I1s9DMUg2ln7tTzNdhE02 
  13.             fY4GVjiCw7i9YJ+cgcMZh8qL0yoilrLpRLzLrRC6rApqYfEwn+5FPKtTt7cCAwEA 
  14.             AaNQME4wHQYDVR0OBBYEFNvFMRtHJ4D327dbRbxhWceXnwd0MB8GA1UdIwQYMBaA 
  15.             FNvFMRtHJ4D327dbRbxhWceXnwd0MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEN 
  16.             BQADgYEAX0I5zpGqI7vzzs8CDyokux1JZzfu+O3P5GfOwUaIG9y01FzxgbL2MRKQ 
  17.             oTXMAed97Q6vHA5cffvteu/rPcerpGmFj5h3wv5u+D0ch5s/Mk/Ug6S+x6k3CC+P 
  18.             kHimi6OEslFecDMhghUtPJAmhOGnTRwLr7hVeJXBHXWCTXA7aGE= 
  19.           </ds:X509Certificate> 
  20.         </ds:X509Data> 
  21.       </ds:KeyInfo> 
  22.     </md:KeyDescriptor> 
  23.     <md:NameIDFormat> 
  24.        urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress 
  25.     </md:NameIDFormat> 
  26.     <md:SingleSignOnService 
  27.       Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
  28.       Location="https://idp.example.com/saml"/> 
  29.     <md:SingleSignOnService  
  30.       Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" 
  31.       Location="https://idp.example.com/saml"/> 
  32.   </md:IDPSSODescriptor> 
  33. </md:EntityDescriptor> 

認證請求

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

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

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

  1. <md:IDPSSODescriptor> 
  2.    <md:KeyDescriptor use=&quot;signing&quot;> 
  3.      <ds:KeyInfo> 
  4.        <ds:X509Data> 
  5.          <ds:X509Certificate> 
  6.            MIICMjCCAZugAwIBAgIBADANBgkqhkiG9w0BAQ0FADA2MQswCQYDVQQGEwJ1czEL 
  7.            MAkGA1UECAwCQ0ExDDAKBgNVBAoMA2lkcDEMMAoGA1UEAwwDaWRwMB4XDTE5MDQy 
  8.            NjE4NTIxOFoXDTIwMDQyNTE4NTIxOFowNjELMAkGA1UEBhMCdXMxCzAJBgNVBAgM 
  9.            AkNBMQwwCgYDVQQKDANpZHAxDDAKBgNVBAMMA2lkcDCBnzANBgkqhkiG9w0BAQEF 
  10.            AAOBjQAwgYkCgYEA1mKmlbr/SiHOhgdROpYeze96mw0WbO+BdJYDceeuNkaw0zOU 
  11.            CKZI6TNgrNsqEnLOyWYy5ywA9XA6Ni2qQTuKqapsMT3I1s9DMUg2ln7tTzNdhE02 
  12.            fY4GVjiCw7i9YJ+cgcMZh8qL0yoilrLpRLzLrRC6rApqYfEwn+5FPKtTt7cCAwEA 
  13.            AaNQME4wHQYDVR0OBBYEFNvFMRtHJ4D327dbRbxhWceXnwd0MB8GA1UdIwQYMBaA 
  14.            FNvFMRtHJ4D327dbRbxhWceXnwd0MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEN 
  15.            BQADgYEAX0I5zpGqI7vzzs8CDyokux1JZzfu+O3P5GfOwUaIG9y01FzxgbL2MRKQ 
  16.            oTXMAed97Q6vHA5cffvteu/rPcerpGmFj5h3wv5u+D0ch5s/Mk/Ug6S+x6k3CC+P 
  17.            kHimi6OEslFecDMhghUtPJAmhOGnTRwLr7hVeJXBHXWCTXA7aGE= 
  18.          </ds:X509Certificate> 
  19.        </ds:X509Data> 
  20.      </ds:KeyInfo> 
  21.    </md:KeyDescriptor> 
  22.    <md:NameIDFormat> 
  23.       urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress 
  24.    </md:NameIDFormat> 
  25.    <md:SingleSignOnService 
  26.      Binding=&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&quot; 
  27.      Location=&quot;https://idp.example.com/saml&quot;></md:SingleSignOnService> 
  28.    <md:SingleSignOnService  
  29.      Binding=&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect&quot; 
  30.      Location=&quot;https://idp.example.com/saml&quot;></md:SingleSignOnService> 
  31.  </md:IDPSSODescriptor> 
  32. /md:EntityDescriptor>" 

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

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

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

認證響應

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

  1. saml2p: Response 
  2. Destination=\"https://sp.example.com/saml/acs\" 
  3. ID=\"id35287812421219341967493380\" 
  4. InResponseTo=\"bcf0b634-67b4-4dc9-a436-4e5cfcfb80e2\" 
  5. IssueInstant=\"2019-04-18T18:51:46.729Z\"> 
  6. <ds:Signature> 
  7. <ds:SignedInfo> 
  8. <ds:CanonicalizationMethod 
  9. Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\" /> 
  10. <ds:SignatureMethod 
  11. Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\" /> 
  12. <ds:Reference URI=\"#id35287812421219341967493380\"> 
  13. <ds:Transforms> 
  14. <ds:Transform 
  15. Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\" /> 
  16. <ds:Transform 
  17. Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\",/> 
  18. </ds:Transforms> 
  19. <ds:DigestMethod 
  20. Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\" /> 
  21. <ds:DigestValue> 
  22. tyLUm4r2isgN+L6sRcqDSEa1Zb7WQbQJG6PpLcf3Mrc= 
  23. </ds:DigestValue> 
  24. </ds:Reference> 
  25. </ds:SignedInfo> 
  26. <ds:SignatureValue> 
  27. XjqbZty/QkqTnMV8YsS2XJ3qgVLPGNC67o/WmzkzoAyl3SBOCGllV4UdijkTjhgykQP7MVXyCql0 
  28. eRtIMJ++rbi3OxCSc0LN67znuTS7cAfcOQzYBtYX2R9w3GlEAO0kZusWYlP3cu/ObmQZUQ7CSgr4 
  29. DRXsVWRhSmmpxHl6klC6c10eWiIlK7Ccpvvvb2hlwl8anyuO/CcKH0n/Rb9vHWtsAlqKXZ8G4X6M 
  30. 77AfRFC7yDWk+8B784109phQxcxoDYjuQNO5IkiRE6J2LnkmuaPoKVyTtpP2JYLiYMSBu8laDsnZ 
  31. I/ewOtBwr16j9oOJpgHPQufQJfvcg+rPEwkptg== 
  32. </ds:SignatureValue> 
  33. <ds:KeyInfo> 
  34. <ds:X509Data> 
  35. <ds:X509Certificate> 
  36. MIICMjCCAZugAwIBAgIBADANBgkqhkiG9w0BAQ0FADA2MQswCQYDVQQGEwJ1czEL 
  37. MAkGA1UECAwCQ0ExDDAKBgNVBAoMA2lkcDEMMAoGA1UEAwwDaWRwMB4XDTE5MDQy 
  38. NjE4NTIxOFoXDTIwMDQyNTE4NTIxOFowNjELMAkGA1UEBhMCdXMxCzAJBgNVBAgM 
  39. AkNBMQwwCgYDVQQKDANpZHAxDDAKBgNVBAMMA2lkcDCBnzANBgkqhkiG9w0BAQEF 
  40. AAOBjQAwgYkCgYEA1mKmlbr/SiHOhgdROpYeze96mw0WbO+BdJYDceeuNkaw0zOU 
  41. CKZI6TNgrNsqEnLOyWYy5ywA9XA6Ni2qQTuKqapsMT3I1s9DMUg2ln7tTzNdhE02 
  42. fY4GVjiCw7i9YJ+cgcMZh8qL0yoilrLpRLzLrRC6rApqYfEwn+5FPKtTt7cCAwEA 
  43. AaNQME4wHQYDVR0OBBYEFNvFMRtHJ4D327dbRbxhWceXnwd0MB8GA1UdIwQYMBaA 
  44. FNvFMRtHJ4D327dbRbxhWceXnwd0MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEN 
  45. BQADgYEAX0I5zpGqI7vzzs8CDyokux1JZzfu+O3P5GfOwUaIG9y01FzxgbL2MRKQ 
  46. oTXMAed97Q6vHA5cffvteu/rPcerpGmFj5h3wv5u+D0ch5s/Mk/Ug6S+x6k3CC+P 
  47. kHimi6OEslFecDMhghUtPJAmhOGnTRwLr7hVeJXBHXWCTXA7aGE= 
  48. </ds:X509Certificate> 
  49. </ds:X509Data> 
  50. </ds:KeyInfo> 
  51. </ds:Signature> 
  52. <saml2p:Status> 
  53. <saml2p:StatusCode 
  54. Value=\"urn:oasis:names:tc:SAML:2.0:status:Success\" /> 
  55. </saml2p:Status> 
  56. <saml2:Assertion 
  57. ID=\"id35287812421980111258419174\" 
  58. IssueInstant=\"2019-04-18T18:51:46.729Z\"> 
  59. <ds:Signature> 
  60. <ds:SignedInfo> 
  61. <ds:CanonicalizationMethod 
  62. Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\" /> 
  63. <ds:SignatureMethod 
  64. Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\" /> 
  65. <ds:Reference URI=\"#id35287812421980111258419174\"> 
  66. <ds:Transforms> 
  67. <ds:Transform 
  68. Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\" /> 
  69. <ds:Transform 
  70. Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\"/> 
  71. </ds:Transforms> 
  72. <ds:DigestMethod 
  73. Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\" /> 
  74. <ds:DigestValue> 
  75. VKPsgTPABNq1SvInCMXd04LZCvRYMnJzEeT5oIs70hw= 
  76. </ds:DigestValue> 
  77. </ds:Reference> 
  78. </ds:SignedInfo> 
  79. <ds:SignatureValue> 
  80. gsUzQuivXX378HkYNI+plBkp1BvPUNmJD+kh825nHwIBNd019IxffVmOfRAQAkZhT6rqxWhO5/Yc 
  81. JGR5J0qjJVmrRrJ/ipT4VfuJsbn346nEFSMU15D0h3UHrvl651C+NStyXsi8Q8502Qe0ChHOtEXM 
  82. rw9HWPwYtJX0rlpNEzLUnEQPvJ4pd3bz9SIl/YXMNTxE7NCDOxPXKtA4namkkweilxTCynM6A1kn 
  83. 6gEWaXhLMwLLAV6kOtivdVksBPzR9BeZ7RPpXeqt0qN62L4NaHq3OsdjgtQr9sllssD1fEek1eU4 
  84. giCzPgb1+LjvD9dpFH5pcLt9YlwHyYgEBBLOQg== 
  85. </ds:SignatureValue> 
  86. <ds:KeyInfo> 
  87. <ds:X509Data> 
  88. <ds:X509Certificate> 
  89. MIICMjCCAZugAwIBAgIBADANBgkqhkiG9w0BAQ0FADA2MQswCQYDVQQGEwJ1czEL 
  90. MAkGA1UECAwCQ0ExDDAKBgNVBAoMA2lkcDEMMAoGA1UEAwwDaWRwMB4XDTE5MDQy 
  91. NjE4NTIxOFoXDTIwMDQyNTE4NTIxOFowNjELMAkGA1UEBhMCdXMxCzAJBgNVBAgM 
  92. AkNBMQwwCgYDVQQKDANpZHAxDDAKBgNVBAMMA2lkcDCBnzANBgkqhkiG9w0BAQEF 
  93. AAOBjQAwgYkCgYEA1mKmlbr/SiHOhgdROpYeze96mw0WbO+BdJYDceeuNkaw0zOU 
  94. CKZI6TNgrNsqEnLOyWYy5ywA9XA6Ni2qQTuKqapsMT3I1s9DMUg2ln7tTzNdhE02 
  95. fY4GVjiCw7i9YJ+cgcMZh8qL0yoilrLpRLzLrRC6rApqYfEwn+5FPKtTt7cCAwEA 
  96. AaNQME4wHQYDVR0OBBYEFNvFMRtHJ4D327dbRbxhWceXnwd0MB8GA1UdIwQYMBaA 
  97. FNvFMRtHJ4D327dbRbxhWceXnwd0MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEN 
  98. BQADgYEAX0I5zpGqI7vzzs8CDyokux1JZzfu+O3P5GfOwUaIG9y01FzxgbL2MRKQ 
  99. oTXMAed97Q6vHA5cffvteu/rPcerpGmFj5h3wv5u+D0ch5s/Mk/Ug6S+x6k3CC+P 
  100. kHimi6OEslFecDMhghUtPJAmhOGnTRwLr7hVeJXBHXWCTXA7aGE= 
  101. </ds:X509Certificate> 
  102. </ds:X509Data> 
  103. </ds:KeyInfo> 
  104. </ds:Signature> 
  105. <saml2:Subject> 
  106. <saml2:NameID> 
  107. jsmith@example.com 
  108. </saml2:NameID> 
  109. <saml2:SubjectConfirmation> 
  110. <saml2:SubjectConfirmationData 
  111. InResponseTo=\"bcf0b634-67b4-4dc9-a436-4e5cfcfb80e2\" 
  112. NotOnOrAfter=\"2019-04-18T18:56:46.730Z\" 
  113. Recipient=\"https://sp.example.com/saml/acs\" /> 
  114. </saml2:SubjectConfirmation> 
  115. </saml2:Subject> 
  116. <saml2:Conditions 
  117. NotBefore=\"2019-04-18T18:46:46.730Z\" 
  118. NotOnOrAfter=\"2019-04-18T18:56:46.730Z\" 
  119. xmlns:saml2=\"urn:oasis:names:tc:SAML:2.0:assertion\"> 
  120. </saml2:Conditions> 
  121. <saml2:AuthnStatement 
  122. AuthnInstant=\"2019-04-18T18:51:46.729Z\" 
  123. SessionIndex=\"bcf0b634-67b4-4dc9-a436-4e5cfcfb80e2\"> 
  124. </saml2:AuthnStatement> 
  125. <saml2:AttributeStatement> 
  126. <saml2:Attribute 
  127. Name=\"logins\"> 
  128. <saml2:AttributeValue> 
  129. root 
  130. </saml2:AttributeValue> 
  131. <saml2:AttributeValue> 
  132. jsmith 
  133. </saml2:AttributeValue> 
  134. </saml2:Attribute> 
  135. <saml2:Attribute 
  136. Name=\"groups\"> 
  137. <saml2:AttributeValue> 
  138. admins 
  139. </saml2:AttributeValue> 
  140. <saml2:AttributeValue> 
  141. developers 
  142. </saml2:AttributeValue> 
  143. </saml2:Attribute> 
  144. </saml2:AttributeStatement> 
  145. </saml2:Assertion> 
  146. </saml2p:Response> 

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

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

對應的響應中有著四個新的標簽：Status、Subject、Conditions、以及AttributeStatement。其中：

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

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

小結

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

總的說來，SAML認證解決了如下三個重要問題：

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

原文標題：How SAML 2.0 Authentication Works and Why It Matters，作者：Ev Kontsevoy

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

 

責任編輯：華軒 來源： 51CTO
語言安全認證機制
相關推薦

2017-11-15 06:20:36

SAML身份認證訪問授權

2011-08-11 10:12:11

2019-06-03 12:58:03

多云標記云計算

2022-09-21 14:07:56

OT安全物聯(lián)網(wǎng)

2009-09-07 09:03:05

思科認證CCNA學習的重要性

2021-06-29 20:50:29

端點安全網(wǎng)絡安全數(shù)據(jù)安全

2016-08-29 20:31:17

2015-06-02 13:10:55

2018-01-23 08:07:37

2009-02-15 16:32:19

2024-01-01 16:16:26

2023-04-28 09:52:27

2023-02-17 15:16:35

2023-06-05 16:04:00

物聯(lián)網(wǎng)物聯(lián)網(wǎng)安全

2019-04-04 13:42:19

2020-01-07 22:26:32

加密網(wǎng)絡安全網(wǎng)絡流量

2021-07-19 16:23:55

數(shù)據(jù)安全滴滴大數(shù)據(jù)

2021-12-28 00:29:00

網(wǎng)絡安全Java編程語言

2023-11-29 14:52:38

2023-10-24 11:07:57

點贊
收藏

51CTO技術棧公眾號