日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

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

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

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

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

SAML的相關術(shù)語

主體(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的內(nèi)置用戶數(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標簽則包含了有待認證響應的身份提供者的公鑰。

 
 
 
 

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

認證請求

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

 
 
 
 

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

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

 
 
 
 

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

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

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

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

認證響應

接著，讓我們回到認證的流程。如果主體輸入了正確的登錄憑據(jù)，身份提供者將會對服務提供者的ACS URL(例如，在本示例中為--https://sp.example.com/saml/acs)執(zhí)行“302重定向”。其正文中包含了認證的響應。如下的Django代碼段是一個簡化版的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\"> 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
  
  
  
  
Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\" /> 
  
  
  
  
  
  
  
  
Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\" /> 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
  
  
  
  
Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\" /> 
  
  
  
  
  
  
  
  
Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\",/> 
  
  
  
  
 
  
  
  
  
  
  
  
  
Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\" /> 
  
  
  
  
 
  
  
  
  
tyLUm4r2isgN+L6sRcqDSEa1Zb7WQbQJG6PpLcf3Mrc= 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
XjqbZty/QkqTnMV8YsS2XJ3qgVLPGNC67o/WmzkzoAyl3SBOCGllV4UdijkTjhgykQP7MVXyCql0 
  
  
  
  
eRtIMJ++rbi3OxCSc0LN67znuTS7cAfcOQzYBtYX2R9w3GlEAO0kZusWYlP3cu/ObmQZUQ7CSgr4 
  
  
  
  
DRXsVWRhSmmpxHl6klC6c10eWiIlK7Ccpvvvb2hlwl8anyuO/CcKH0n/Rb9vHWtsAlqKXZ8G4X6M 
  
  
  
  
77AfRFC7yDWk+8B784109phQxcxoDYjuQNO5IkiRE6J2LnkmuaPoKVyTtpP2JYLiYMSBu8laDsnZ 
  
  
  
  
I/ewOtBwr16j9oOJpgHPQufQJfvcg+rPEwkptg== 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
MIICMjCCAZugAwIBAgIBADANBgkqhkiG9w0BAQ0FADA2MQswCQYDVQQGEwJ1czEL 
  
  
  
  
MAkGA1UECAwCQ0ExDDAKBgNVBAoMA2lkcDEMMAoGA1UEAwwDaWRwMB4XDTE5MDQy 
  
  
  
  
NjE4NTIxOFoXDTIwMDQyNTE4NTIxOFowNjELMAkGA1UEBhMCdXMxCzAJBgNVBAgM 
  
  
  
  
AkNBMQwwCgYDVQQKDANpZHAxDDAKBgNVBAMMA2lkcDCBnzANBgkqhkiG9w0BAQEF 
  
  
  
  
AAOBjQAwgYkCgYEA1mKmlbr/SiHOhgdROpYeze96mw0WbO+BdJYDceeuNkaw0zOU 
  
  
  
  
CKZI6TNgrNsqEnLOyWYy5ywA9XA6Ni2qQTuKqapsMT3I1s9DMUg2ln7tTzNdhE02 
  
  
  
  
fY4GVjiCw7i9YJ+cgcMZh8qL0yoilrLpRLzLrRC6rApqYfEwn+5FPKtTt7cCAwEA 
  
  
  
  
AaNQME4wHQYDVR0OBBYEFNvFMRtHJ4D327dbRbxhWceXnwd0MB8GA1UdIwQYMBaA 
  
  
  
  
FNvFMRtHJ4D327dbRbxhWceXnwd0MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEN 
  
  
  
  
BQADgYEAX0I5zpGqI7vzzs8CDyokux1JZzfu+O3P5GfOwUaIG9y01FzxgbL2MRKQ 
  
  
  
  
oTXMAed97Q6vHA5cffvteu/rPcerpGmFj5h3wv5u+D0ch5s/Mk/Ug6S+x6k3CC+P 
  
  
  
  
kHimi6OEslFecDMhghUtPJAmhOGnTRwLr7hVeJXBHXWCTXA7aGE= 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
  
  
  
  
Value=\"urn:oasis:names:tc:SAML:2.0:status:Success\" /> 
  
  
  
  
 
  
  
  
  
  
  
  
  
ID=\"id35287812421980111258419174\" 
  
  
  
  
IssueInstant=\"2019-04-18T18:51:46.729Z\"> 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
  
  
  
  
Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\" /> 
  
  
  
  
  
  
  
  
Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\" /> 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
  
  
  
  
Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\" /> 
  
  
  
  
  
  
  
  
Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\"/> 
  
  
  
  
 
  
  
  
  
  
  
  
  
Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\" /> 
  
  
  
  
 
  
  
  
  
VKPsgTPABNq1SvInCMXd04LZCvRYMnJzEeT5oIs70hw= 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
gsUzQuivXX378HkYNI+plBkp1BvPUNmJD+kh825nHwIBNd019IxffVmOfRAQAkZhT6rqxWhO5/Yc 
  
  
  
  
JGR5J0qjJVmrRrJ/ipT4VfuJsbn346nEFSMU15D0h3UHrvl651C+NStyXsi8Q8502Qe0ChHOtEXM 
  
  
  
  
rw9HWPwYtJX0rlpNEzLUnEQPvJ4pd3bz9SIl/YXMNTxE7NCDOxPXKtA4namkkweilxTCynM6A1kn 
  
  
  
  
6gEWaXhLMwLLAV6kOtivdVksBPzR9BeZ7RPpXeqt0qN62L4NaHq3OsdjgtQr9sllssD1fEek1eU4 
  
  
  
  
giCzPgb1+LjvD9dpFH5pcLt9YlwHyYgEBBLOQg== 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
MIICMjCCAZugAwIBAgIBADANBgkqhkiG9w0BAQ0FADA2MQswCQYDVQQGEwJ1czEL 
  
  
  
  
MAkGA1UECAwCQ0ExDDAKBgNVBAoMA2lkcDEMMAoGA1UEAwwDaWRwMB4XDTE5MDQy 
  
  
  
  
NjE4NTIxOFoXDTIwMDQyNTE4NTIxOFowNjELMAkGA1UEBhMCdXMxCzAJBgNVBAgM 
  
  
  
  
AkNBMQwwCgYDVQQKDANpZHAxDDAKBgNVBAMMA2lkcDCBnzANBgkqhkiG9w0BAQEF 
  
  
  
  
AAOBjQAwgYkCgYEA1mKmlbr/SiHOhgdROpYeze96mw0WbO+BdJYDceeuNkaw0zOU 
  
  
  
  
CKZI6TNgrNsqEnLOyWYy5ywA9XA6Ni2qQTuKqapsMT3I1s9DMUg2ln7tTzNdhE02 
  
  
  
  
fY4GVjiCw7i9YJ+cgcMZh8qL0yoilrLpRLzLrRC6rApqYfEwn+5FPKtTt7cCAwEA 
  
  
  
  
AaNQME4wHQYDVR0OBBYEFNvFMRtHJ4D327dbRbxhWceXnwd0MB8GA1UdIwQYMBaA 
  
  
  
  
FNvFMRtHJ4D327dbRbxhWceXnwd0MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEN 
  
  
  
  
BQADgYEAX0I5zpGqI7vzzs8CDyokux1JZzfu+O3P5GfOwUaIG9y01FzxgbL2MRKQ 
  
  
  
  
oTXMAed97Q6vHA5cffvteu/rPcerpGmFj5h3wv5u+D0ch5s/Mk/Ug6S+x6k3CC+P 
  
  
  
  
kHimi6OEslFecDMhghUtPJAmhOGnTRwLr7hVeJXBHXWCTXA7aGE= 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
jsmith@example.com 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
  
  
  
  
InResponseTo=\"bcf0b634-67b4-4dc9-a436-4e5cfcfb80e2\" 
  
  
  
  
NotOnOrAfter=\"2019-04-18T18:56:46.730Z\" 
  
  
  
  
Recipient=\"https://sp.example.com/saml/acs\" /> 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
  
  
  
  
NotBefore=\"2019-04-18T18:46:46.730Z\" 
  
  
  
  
NotOnOrAfter=\"2019-04-18T18:56:46.730Z\" 
  
  
  
  
xmlns:saml2=\"urn:oasis:names:tc:SAML:2.0:assertion\"> 
  
  
  
  
 
  
  
  
  
  
  
  
  
AuthnInstant=\"2019-04-18T18:51:46.729Z\" 
  
  
  
  
SessionIndex=\"bcf0b634-67b4-4dc9-a436-4e5cfcfb80e2\"> 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
  
  
  
  
Name=\"logins\"> 
  
  
  
  
 
  
  
  
  
root 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
jsmith 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
  
  
  
  
Name=\"groups\"> 
  
  
  
  
 
  
  
  
  
admins 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
developers 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
  
  
  
  
 
 
 
 
 

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

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

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

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

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

小結(jié)

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

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

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

網(wǎng)站名稱：安全斷言標記語言SAML2.0的認證機制與重要性
文章位置：http://www.dlmjj.cn/article/cceedss.html