WCF開發(fā)框架為我們帶來了許多好處。一個(gè)功能強(qiáng)大的開發(fā)工具當(dāng)然要具備良好的安全性能。在這里我們就來講講有關(guān)WCF安全的相關(guān)知識(shí)。#t#

對(duì)于一個(gè)應(yīng)用程序來說，最重要的特性之一就是安全性。例如，安全方面的需求往往會(huì)最早被提出，安全方面Bug的優(yōu)先級(jí)和危害程度往往都被定為***。有時(shí)候?yàn)榱颂岣甙踩裕€需要犧牲一定的性能或者其他因素。因?yàn)樾阅埽梢酝ㄟ^一些別的方式，例如添加一臺(tái)服務(wù)器作負(fù)載均衡來解決（順便插一句，我現(xiàn)在覺得對(duì)于企業(yè)來說，能夠用錢解決的往往就不是問題了），或者在之后的版本中進(jìn)行優(yōu)化；但是如果出了安全性方面的漏洞，很可能就已經(jīng)造成了無法彌補(bǔ)的損失。

試想，如果Windows Live Passport出現(xiàn)了安全上的漏洞導(dǎo)致用戶信息泄露，這將會(huì)引出多大的風(fēng)波，對(duì)于微軟來說會(huì)造成多少名譽(yù)上的損害。但是如果性能上出現(xiàn)了問題——這方面例如Windows Live Space或Hotmail的早期版本都不怎么樣，但是在優(yōu)化之后還是吸引了大量的用戶群體。

WCF安全是如此的重要，自然WCF也會(huì)為它提供了良好的支持，否則也無法稱之為一個(gè)成熟的模型了（我認(rèn)為，微軟希望，也正在把WCF變成.NET或者說Windows平臺(tái)下分布式通信的事實(shí)標(biāo)準(zhǔn)）。但是雖然WCF提出了豐富而強(qiáng)大的安全性支持，但是如果使用不當(dāng)，依舊會(huì)產(chǎn)生安全方面的問題（同樣的例子還有Sql注入，要保證安全型還是必須通過良好的編程實(shí)踐來達(dá)成），甚至還不如不依賴WCF的功能，直接使用傳統(tǒng)的方式，例如使用硬件或軟件防火墻來阻止非法的連接。

反過來說，選擇什么樣的安全實(shí)踐也是要考慮到項(xiàng)目的實(shí)際情況。例如有的時(shí)候我們的確可以使用傳統(tǒng)的方式來保證安全性，再今后的版本中再采用高級(jí)的實(shí)踐——尤其我們現(xiàn)在有了WCF提供的模型，我們的優(yōu)化可能只是部署一個(gè)新的程序集，然后更新一下配置而已。

Service Model和Channel Layer

WCF提出的通信模型主要可以分為兩大部分：Service Model和Channel Layer。它們各司其職，“互不干涉內(nèi)政”，因此，能夠自由地組合與擴(kuò)展，使開發(fā)人員能夠利用WCF提出的模型來輕松實(shí)現(xiàn)強(qiáng)大的通信功能。不過事實(shí)上，按照官方的說法，Channel Layer是Service Model的組成部分（而且官方的說法的確還是有道理啊），但是我在了解了這些內(nèi)容之后還是認(rèn)為將兩者概念分開為好，希望能夠就這方面的概念問題和大家討論一下。

WSDL是描述一個(gè)服務(wù)的XML格式的語言。通過一個(gè)服務(wù)的WSDL我們可以得知這個(gè)服務(wù)的地址、服務(wù)使用的協(xié)議以及服務(wù)中的各種具體定義（例如定義了哪些消息等等）。顯然，如果每次生成服務(wù)時(shí)都要自己編寫代碼輸出大段復(fù)雜的WSDL，或者在使用服務(wù)時(shí)都要解析WSDL并且在請(qǐng)求時(shí)還需要自己生成SOAP內(nèi)容，這樣的開發(fā)效率就實(shí)在是太低了。

因此，成熟的框架會(huì)提供一種“抽象”機(jī)制，使開發(fā)人員能夠輕松的定義服務(wù)，盡可能的將注意力集中在業(yè)務(wù)邏輯的實(shí)現(xiàn)上。例如使用ASP.NET釋放Web Services，或者利用.NET Framework中的wsdl.exe根據(jù)某個(gè)服務(wù)的WSDL描述來生成代理。這些框架和工具都能夠大大提高我們的開發(fā)效率。

WCF中的Service Model就是這樣的一種抽象。簡單地說，它可以被認(rèn)作是一個(gè)與WSDL產(chǎn)生映射的模型。在Service Model中，與WSDL各部分相對(duì)應(yīng)的概念被稱作為address、binding和contract，這就是被各種資料中所提到的“A、B、C”。除了提供了“定義”這樣的模型（用來與WSDL對(duì)應(yīng)）之外，Service Model還負(fù)責(zé)了上述模型與外部請(qǐng)求或者回復(fù)信息的轉(zhuǎn)化。

例如，我們的Host一旦接受到了一個(gè)請(qǐng)求，那么它會(huì)把這個(gè)請(qǐng)求內(nèi)容反序列化成為一個(gè)Message類型的對(duì)象，并交給Service Model處理。此時(shí)Service Model開始工作，例如它會(huì)構(gòu)造出處理這個(gè)請(qǐng)求的環(huán)境，識(shí)別出該用哪個(gè)類型來處理請(qǐng)求，選擇或者創(chuàng)建一個(gè)類型的實(shí)例，確定應(yīng)該調(diào)用的方法，隨后調(diào)用方法，得到一個(gè)結(jié)果對(duì)象。

然后Service Model同樣負(fù)責(zé)將這個(gè)結(jié)果對(duì)象轉(zhuǎn)化為一個(gè)Message類型的對(duì)象，最終將其序列化并輸出（整個(gè)過程有十多個(gè)步驟，我這里只是提到了一些最重要并且最容易理解的環(huán)節(jié)。由此可見WCF的可擴(kuò)展性是多么的強(qiáng)大）。如果使用WCF生成調(diào)用服務(wù)的代理，那么Service Model工作性質(zhì)還是差不多，只是方向相反而已。

那么是由什么組件負(fù)責(zé)將一個(gè)外部的請(qǐng)求反序列化成為一個(gè)Message對(duì)象，待方法調(diào)用完成之后，又將表示結(jié)果的Message序列化成為輸出的內(nèi)容呢（如果使用WCF作為客戶端代理，那么就變成將Message序列化為請(qǐng)求的內(nèi)容，并且將收到的回復(fù)內(nèi)容反序列化成Message對(duì)象）？這就是Channel Layer的作用。

Channel Layer定義個(gè)一個(gè)由一系列Channel組成的Stack，Message對(duì)象在穿越這個(gè)Channel Stack的時(shí)候會(huì)經(jīng)過每個(gè)Channel的處理，一步步地“形變”，最終成為了我們需要“數(shù)據(jù)形態(tài)”。例如服務(wù)返回的Message對(duì)象在經(jīng)過了功能為SOAP XML轉(zhuǎn)化的Channel之后便成了SOAP XML的形式，然后再經(jīng)由一個(gè)負(fù)責(zé)加密的Channel則成為了Encrypted數(shù)據(jù)（當(dāng)然實(shí)際的步驟也沒有那么簡單），最終經(jīng)由一個(gè)負(fù)責(zé)TCP/IP信道傳送的Channel輸送出去。

試想，如果我們自定義一個(gè)Channel將Message轉(zhuǎn)化為JSON格式，然后再使用一個(gè)Channel通過一個(gè)HTTP通道返回?cái)?shù)據(jù)，那么不就能夠支持ASP.NET AJAX的Web Service請(qǐng)求功能了嗎？沒錯(cuò)，的確可以這樣。事實(shí)上在新的ASP.NET Futures類庫中就提供了這樣的組件，它們是學(xué)習(xí)如何擴(kuò)展WCF的優(yōu)秀范例。不過這已經(jīng)是題外話了，有機(jī)會(huì)我們可以另起一個(gè)話題再說。

不過這里又要談一下我個(gè)人的觀點(diǎn)了，因?yàn)槲覍?duì)于Channel Stack的理解和官方說法有一定出入。無論從目前的官方文檔，亦或是各類技術(shù)會(huì)議上談到的Channel Layer，都是由一個(gè)一個(gè)Channel，“并列”地組合成一個(gè)Channel Stack。然后Message就像一個(gè)原材料通過生產(chǎn)線一樣，最終得到了一個(gè)成品。

但是在我看來，Channel之間的關(guān)系不是并列的，而是使用了類似于“裝飾模式”的嵌套的做法來實(shí)現(xiàn)的。在我看來，Channel與Channel之間是包含關(guān)系，Service Model將Message交給了最外層的Channel處理，而最外層的Channel根據(jù)它定義的某種邏輯，配合它鄰近的那個(gè)下層的Channel處理的結(jié)果來操作這個(gè)Message對(duì)象，而不是簡單地將處理的結(jié)果交給下一個(gè)Channel。這一點(diǎn)從自定義Channel的方式上就可以看出，基本上每個(gè)Channel內(nèi)部都會(huì)用一個(gè)名為innerChannel的私有Field來保存下一個(gè)Channel，并且在自己的某些方法中使用innerChannel的方法。

根據(jù)我的理解可以得到一些推論，例如關(guān)閉一個(gè)Channel時(shí)，該Channel必須負(fù)責(zé)將它的innerChannel對(duì)象關(guān)閉；我們可以實(shí)現(xiàn)一個(gè)最簡單同時(shí)無用的Channel，將所有的方法都直接委托給innerChannel，等等。而這些推論都是擴(kuò)展Channel Layer的正確做法或結(jié)論，因此，我還是覺得自己的理解更加合理一些。當(dāng)然，如果您在這方面有什么看法，也希望能夠和您進(jìn)行交流。

為什么要理解Service Model和Channel Layer？

似乎說了半天，我還沒有涉及到WCF安全的支持，卻在大談特談一些“概念”。但是我認(rèn)為，了解WCF的一些模型是掌握WCF的基礎(chǔ)（我個(gè)人非常注重模型，也就是一個(gè)框架是如何抽象外部事物的，例如ASP.NET如何將HTTP請(qǐng)求抽象成WebForm）。

只有了解了Service Model和Channel Layer的設(shè)計(jì)目的和功能，才能正確理解一些安全方面的做法是如何與這些模型結(jié)合的。例如，Channel Layer可以提供哪些WCF安全上的保證，為什么Authentication操作是在Channel Layer中進(jìn)行，而Authorization卻是Service Model提供的呢？

WCF框架的設(shè)計(jì)并非隨性而為，其中有著充分的理由，是那些世界***架構(gòu)師們智慧和經(jīng)驗(yàn)的結(jié)晶。當(dāng)從“模型”的角度理解到這些內(nèi)容之后，對(duì)于框架的使用往往就可以更上一層樓了。

就拿我自己的經(jīng)驗(yàn)來說，一開始必須“死記硬背”或者對(duì)照著Sample Code才能寫出代碼。而理解了模型之后，似乎代碼或配置該怎么寫，寫在什么地方都是順理成章的事情，在一些細(xì)節(jié)方面翻閱一下MSDN就能夠解決開發(fā)中的大部分的問題。