WCF分布式開發步步為贏(14):WCF安全編程--基本概念
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)獲取傳輸安全性。傳輸模式的優點是可以被廣泛采用、可用于多個平臺以及計算較為簡單。但是,它的缺點是只能保證點到點的消息安全。
消息安全模式使用 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 |
No |
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
3.WSE3.0構建Web服務安全(1):WSE3.0安全機制與實例開發
4.WSE3.0構建Web服務安全(2):非對稱加密、公鑰、密鑰、證書、簽名的區別和聯系以及X.509 證書的獲得和管理
5.http://msdn.microsoft.com/zh-cn/library/ms731069.aspx
6.http://technet.microsoft.com/zh-cn/library/cc768063(en-us).aspx
7.http://www.microsoft.com/msj/0899/kerberos/kerberos.aspx

浙公網安備 33010602011771號