WCF分散式開發步步為贏(14):WCF安全程式設計–基本概念

技術小胖子發表於2017-11-17
分散式程式設計
  WCF安全機制是個非常複雜的問題，因為涉及的知識點較多，所以今天這個文章，會分析進行WCF安全開發應該瞭解的哪些知識點。如何檢視資料。為了更好地理解WCF安全相關知識，我把WCF安全機制主要知識點整理為圖表。本章以介紹WCF安全機制的基礎概念為主。
  要學習WCF安全程式設計，你應該學習什麼首先掌握什麼基礎知識？很多時候會因為缺乏系統的安全概念，在進行WCF安全程式設計開發的時候，遇到很多問題，比如所證書，這個概念相信很多初學者第一次接觸的時候花費了很多時間。我當時在做WSE安全開發的時候就查閱了很多資料。那麼哪些是WCF安全開發應該掌握的知識點呢？今天我們就在這裡做詳細的介紹：
    Windows Communication Foundation (WCF) 是一個基於 SOAP 訊息的分散式程式設計平臺，我們可以使用現有技術（如 HTTPS）、Windows 整合安全性或對使用者進行身份驗證的使用者名稱和密碼生成安全的分散式應用程式。WCF 基於現有安全性基礎結構和 SOAP 訊息的經驗證的安全標準提供可互操作的安全訊息交換通用平臺。 通過使用 WCF的安全機制，我們可以可以在Internet 範圍內跨多個 Windows 域進行服務和客戶端的資料互動。下面會一次介紹WCF安全相關的一些知識點： 
【0】安全開發必備知識點：
（1）對稱加密演算法DES，也叫金鑰演算法。
（2）非對稱加密演算法，也叫公鑰演算法。使用一對金鑰，配合使用。如RSA演算法；
（3）雜湊演算法：MD5（Message Digest5訊息摘要演算法），SHA1，SHA256等概念。簽名，也是在是雜湊演算法的應用。
（4）WS-Security安全規範。這個是重要的安全規範，從Web Service ，WSE3.0 到現在的WCF服務都提供了支援。
（5）證書。這個是非對稱加密的一個應用。CA證書管理機構。如何建立證書和管理證書。等概念有所瞭解。
    演算法這裡主要討論的是如何應用，即如何進行加密、解密、訊息簽名等問題。你對這些概念瞭解以後才會更好的理解WCF安全。
其實早在《WSE3.0構建Web服務安全(4) 》系列裡已經詳細討論過這個問題。如果你看過這個系列的文章，這個些相關概念理解起來會容易許多。安全的相關知識點都有介紹，這個也是當初為什麼花時間來學習WSE3.0的原因。你可以參考WSE3.0構建Web服務安全(1):WSE3.0安全機制與例項開發 和WSE3.0構建Web服務安全(2):非對稱加密、公鑰、金鑰、證書、簽名的區別和聯絡以及X.509 證書的獲得和管理 。後面的討論又對文章進行了補充。幾乎涵蓋了所有的WCF安全需要的所有的基本知識點。
【1】WCF身份驗證機制：

    WCF與現有的Windows平臺上的身份驗證機制很好地結合以外，還支援WS-Security安全規範，以及使用者定製擴充套件驗證模式，安全令牌方式。如果你關注過WSE3.0相關的技術文章，一定感覺不會陌生，這些安全機制在WSE3.0中已經完全支援。這些都是WCF聲稱繼承WSE安全機制的最好證明。延續微軟平臺的的一貫做法。優秀模型的複用與擴充套件。關於安全的概念可以再參考WSE3.0構建Web服務安全(1):WSE3.0安全機制與例項開發 。WCF支援的身份驗證機制可以參考下圖：

    一下是對各種客戶端身份驗證方式的說明：
(1)None:客戶端為匿名客戶端。在這種情況下，每個客戶端擁有一個自己的證書，比如身份證。服務會使用證書來確保服務客戶端的標識。我們經常使用HTTPS 訪問網站，比如登陸一些安全級別較高的網站情況類似，或者使用網上銀行時候，你的客戶端證書就會起到鑑別客戶端的作用。

(2)UserName:客戶端將提供使用者名稱和密碼。在這種情況下，服務會使用證書向客戶端驗證其標識。另外就是證書還將用加密客戶端的使用者名稱和密碼，保證訊息在傳輸過程中的安全。這個方式也是常見的加密方式。我會在後續文章裡給出實現程式碼。
(3)Windows:需要Windows AD支援。一般使用在企業區域網內部。客戶端和服務都會使用 Windows 帳戶進行身份驗證。Windows Communication Foundation 將會就 Kerberos 或 NTLM 進行協商，如果存在域，則優先選擇 Kerberos（NTLM 實際上不會向客戶端驗證服務的身份，而只會向服務驗證客戶端的身份）。如果您想要使用 Kerberos，則必須讓客戶端根據配置中的服務主體名稱驗證服務的身份。如果您要在域環境中為客戶端構建服務，您應明確地為其提供傳送 Windows 賬號的選項。
(4)Certificate:服務將具有一個證書（客戶端的公鑰），客戶端也具有一個其自己的證書（服務端的公鑰）。當客戶端向服務端傳送訊息時，使用證書加密訊息，服務端使用私鑰解密。反之亦然。證書就是包含公鑰，證書標識，主題，指紋，簽名演算法等的一個檔案。
(5)IssuedToken:安全令牌的概念在WSE3.0裡曾經涉及到。它允許您的服務從安全性令牌服務 (STS) 接受一組簽名的宣告。因為它可以啟用聯合標識方案和 InfoCard。當您與某個合作伙伴組織聯合時，您將允許該合作伙伴通過任何合適的技術對其自己的使用者進行身份驗證。在最理想的情況下，這將允許該合作伙伴組織中的使用者通過單一登入使用您的服務，即便他們並不與您使用同一個 Active Directory 域，或不受您的信任。該合作伙伴組織中的使用者需要使用 STS 進行身份驗證，而 STS 可以發出一個簽名的安全宣告標記語言 (Security Assertion Markup Language, SAML) 令牌。您既可以直接接受該令牌，也可以要求將該令牌呈送給您組織中的 STS，以便讓其評估該合作伙伴的宣告，併發出第二個您可以使用的 SAML 令牌。理解起來有點複雜。實際也是一個標識，鑑別客戶端的一個標識。就是一種更加靈活的身份驗證方式。

   好比你現在使用中國護照，有一天突然聯合國實現了一種新的護照，全球統一護照，你可以進入任何一個國家，即使你在中國辦理，但是其他國家可以再你落地的時候驗證你的護照的有效性。然後告訴其他國家，共享著這次驗證的結果。你的護照就是令牌。需要後續鑑別的身份證明。Issued這個單詞的作用就在這裡。需要鑑別的令牌。

    UserName方式容易實現，但是在WCF框架下需要使用服務證書，這個是相對WSE3.0改變的地方。如果結合證書使用的話，會使的這種方式適合在Internet中使用。安全性較高。適合對釋出到Internet的WCF服務常見的身份驗證方式。X.509證書驗證方式相對嚴謹，要求客戶端提供有效的證書憑證，也就是每個客戶端都要維護一個自己的證書，呼叫服務前，通過SOAP訊息傳遞到WCF服務，WCF進行身份驗證。這個需要CA支援。或者需要申請第三方商業證書。

  定製方式也比較常見，使用者根據需要定製自己的身份驗證機制，如指紋，基因等技術。來代替現有的身份驗證方式。

【2】WCF傳輸安全模式：

    WCF transfer Security mode包含5種方式：None,Transport,Message,Mixed,Both.這裡的翻譯直接翻譯會導致奇異，因為這裡還有一個概念就是Transport安全。選擇不翻譯更好，兩者的中文直譯反而難以理解。記住transfer Security 包含Transport,Message等5中安全模式，Transport,Message也是最長使用的安全模式。如下圖：
    傳輸安全模式使用傳輸級協議（如 HTTPS）獲取傳輸安全性。傳輸模式的優點是可以被廣泛採用、可用於多個平臺以及計算較為簡單。但是，它的缺點是隻能保證點到點的訊息安全。
(1)混合模式: 使用傳送安全實現完整性、保密性和伺服器身份驗證。使用訊息安全（WS-Security 和其他標準）實現客戶端身份驗證。（此模式的列舉值是 TransportWithMessageCredential。）


(2)訊息和傳送: 在傳送級別和訊息級別都執行保護和身份驗證。此模式僅在 <netMsmqBinding> 元素中可用。


    訊息安全模式使用 WS-Security（和其他規範）實現傳輸安全性。因為訊息安全性直接應用於 SOAP 訊息並與應用程式資料一起包含在 SOAP 訊息內，它的優點是獨立於傳輸協議、可擴充套件性更強以及可確保端到端安全性（與點到點相對），實現在整個Internet網路中的訊息傳播安全；它的缺點是比傳輸安全性模式慢很多倍，因為它必須處理 SOAP 訊息，對訊息加密，解密和簽名等操作。

【3】WCF安全模式與繫結協議：

     Net相關的繫結協議預設支援transport安全模式，而WS相關繫結預設支援訊息安全模式。  BasicHttpBinding 繫結可支援基本安全配置檔案，而 WSHttpBinding 繫結則支援最新的安全標準，例如 WS-Security 1.1 和 WS-SecureConversation。通過對這些標準的支援，WCF 安全性可與除 Microsoft Windows 之外的作業系統和平臺上承載的 Web 服務進行互操作和整合。具體關係可以參考下表：
繫結安全模式
None
Transport
Message
Mixed
Both
BasicHttpBinding
Yes (Default)
Yes
Yes
Yes
No
NetTcpBinding
Yes
Yes (Default)
Yes
Yes
No
NetPeerTcpBinding
Yes
Yes (Default)
Yes
Yes
No
NetNamedPipeBinding
Yes
Yes (Default)
No
No
No
WSHttpBinding
Yes
Yes
Yes (Default)
Yes
No
WSFederationHttpBinding
Yes
No
Yes (Default)
Yes
No
WSDualHttpBinding
Yes
No
Yes (Default)
No
No
NetMsmqBinding
Yes
Yes (Default)
Yes
No
Yes
【4】Transport安全模式與客戶端憑據：

   Transport安全模式與客戶端驗證方式包括以下4種：None,Windows,UserName，Certificate也就是證書（非對稱加密演算法裡，包含公鑰等資訊的一種檔案形式）。客戶端憑據中文翻譯彆扭，不好理解。clientCredential。通俗來說：就是用什麼樣的方式來驗證客戶端。即客戶端提供的證件。具體由服務端決定使用哪種方式。下面是繫結協議和客戶端驗證方式在transport模式下的對應關係：
繫結客戶端憑據
None
Windows
Username
Certificate
BasicHttpBinding
Yes (Default)
Yes
Yes
Yes
NetTcpBinding
Yes
Yes (Default)
No
Yes
NetPeerTcpBinding
No
No
Yes (Default)
Yes
NetNamedPipeBinding
No
Yes (Default)
No
No
WSHttpBinding
Yes
Yes (Default)
Yes
Yes
WSFederationHttpBinding
N/A
N/A
N/A
N/A
WSDualHttpBinding
N/A
N/A
N/A
N/A
NetMsmqBinding
Yes
Yes (Default)
No
Yes


【5】 訊息安全模式與客戶端憑據： 

     相對tansport安全模式來說，訊息安全模式下我們可以多使用一種客戶端驗證方式：Issued token令牌。訊息安全模式增加支援的安全令牌機制。

     IssuedToken:安全令牌的概念在WSE3.0裡曾經涉及到。它允許您的服務從安全性令牌服務 (STS) 接受一組簽名的宣告。因為它可以啟用聯合標識方案和 InfoCard。當您與某個合作伙伴組織聯合時，您將允許該合作伙伴通過任何合適的技術對其自己的使用者進行身份驗證。在最理想的情況下，這將允許該合作伙伴組織中的使用者通過單一登入使用您的服務，即便他們並不與您使用同一個 Active Directory 域，或不受您的信任。該合作伙伴組織中的使用者需要使用 STS 進行身份驗證，而 STS 可以發出一個簽名的安全宣告標記語言 (Security Assertion Markup Language, SAML) 令牌。您既可以直接接受該令牌，也可以要求將該令牌呈送給您組織中的 STS，以便讓其評估該合作伙伴的宣告，併發出第二個您可以使用的 SAML 令牌。理解起來有點複雜。實際也是一個標識，鑑別客戶端的一個標識。就是一種更加靈活的身份驗證方式。


    這裡主要是為什麼transport模式不支援，而訊息模式支援，因為安全令牌，需要後續組織中的一個成員進行後續的身份鑑別，然後進行驗證結果的共享。Transportat模式只限制點對點傳輸安全，因而不適合這種驗證方式。
繫結客戶端憑據
None
Windows
Username
Certificate
Issued token
BasicHttpBinding
No
No
Yes
Yes
No
NetTcpBinding
Yes
Yes (Default)
Yes
Yes
Yes
NetPeerTcpBinding
N/A
N/A
N/A
N/A
N/A
NetNamedPipeBinding
N/A
N/A
N/A
N/A
N/A
WSHttpBinding
Yes
Yes (Default)
Yes
Yes
Yes
WSFederationHttpBinding
N/A
N/A
N/A
N/A
N/A
WSDualHttpBinding
Yes
Yes (Default)
Yes
Yes
Yes
NetMsmqBinding
Yes
Yes (Default)
Yes
Yes
Yes
【6】總結：
   WCF 安全性與現有傳輸安全模型整合，並且可對基於 SOAP 訊息安全的新傳輸安全模型使用現有基礎結構。支援IIS結合的所有安全性解決方案。安全套接字層 (SSL) 或 Kerberos 協議。也支援Windows身份驗證方式，使用 Active Directory 的 Windows 域。而對WS-Security安全規範的支援又使其可以在網際網路中實現安全的訊息傳輸。   這些基礎知識，基本是WCF安全機制要使用的主要的知識點。這裡之所以單獨整理出來，主要是因為：

（1）安全的概念由來已久，而與安全相關的演算法或者相關概念，如加密、解密、證書、簽名等概念大家必須有所瞭解。這個是進行安全程式設計的基礎。如果對此基本概念不瞭解，在後續的學習中會寸步難行。

（2）WS-Security相關知識點，在WSE3.0裡已經提供了很好的支援，WCF整合過來以後，也是對WCF宣稱支援早期WSE優勢的重要證據。

也使得WCF具有可以實現向Web Service一樣跨平臺的安全的重要特性。例如許多自定義安全驗證方式使用就是重寫積累的Validate方法。這個和WSE3.0非常相似，使用者自定義實現使用者名稱和密碼的驗證，重寫以後，WCF框架會自動呼叫這個方法。驗證失敗會丟擲異常。

（3）WCF安全更加複雜，除了支援先有的安全框架，還有結合自身的要求實現與繫結等協議的結合，為此，WCF提供了自己的安全通道，來實現對安全機制的支援。訊息的加密、簽名和解密都是在這裡完成。來適用不同的安全驗證場景。

（4）安全級別的提升，除了顯示配置安全模式為None意外，WCF大部分訊息安全模式在使用WS繫結都要求提供證書支援。比如UserName的訊息安全模式，伺服器必須提供證書，而且要是可信任的證書。這個和早期的Web Service直接在Soap 訊息Header裡寫明文的使用者名稱和密碼。WSE3.0安全只啟用UserName驗證不同。

    在瞭解完這些基礎概念以後，我會在後續文章裡給出更多講解。因為涉及的知識點太多。如果只講一個問題，或者簡單給出實現，難以系統掌握WCF安全開發。所以為了更好的學習WCF安全程式設計,這裡現從安全的總體概念入手，系統介紹安全的主要知識點以後，再來進行下面的學習。

我在下一篇會介紹USerName方式的客戶單身份驗證的實現原理和過程。包括實現程式碼。

   謝謝~  

   

參考資料：

1.programming WCF Services

2.http://msdn.microsoft.com/en-us/library/ms735093.aspx
 本文轉自 frankxulei 51CTO部落格，原文連結：http://blog.51cto.com/frankxulei/320422，如需轉載請自行聯絡原作者


相關文章