整個(gè)安全傳輸是在WCF的信道層進(jìn)行的，而綁定是信道層的締造者，所以終結(jié)點(diǎn)采用哪種類型的綁定以及對(duì)綁定的屬性進(jìn)行怎樣的設(shè)置決定了信道層最終采用何種機(jī)制實(shí)現(xiàn)消息的安全傳輸。具體來(lái)說(shuō)，我們可以通過(guò)綁定設(shè)置最終采用的安全模式，以及基于相應(yīng)安全模式下進(jìn)行認(rèn)證和消息保護(hù)的行為。

　　一、Binding安全相關(guān)的應(yīng)用編程接口

　　不同的綁定類型由于其采用的傳輸協(xié)議不同，應(yīng)用的場(chǎng)景也各有側(cè)重，很難提供一種統(tǒng)一的應(yīng)用編程接口完成基于不同綁定的安全設(shè)置，所以每一種綁定都具有各自用于安全設(shè)置相關(guān)的類型。但是基于對(duì)安全的設(shè)置，大部分系統(tǒng)預(yù)定義綁定（不是所有）都具有類似于如下代碼片斷所示的屬性定義。

   1: Public class XxxBinding

   2: {

   3:     Public XxxSecurity Security {}

   4: }

   5: Public class XxxSecurity

   6: {

   7:     Public XxxSecurityMode Mode{get;set;}

   8: Public XxxTransportSecurity  Transport{get;set;}

   9:     Public XxxMessageSecurity    Message{get;set;}

  10: }

　　對(duì)于某個(gè)綁定XxxBinding（Xxx泛指某種綁定類型，所有帶Xxx前綴的類型并不意味著它們代表完全一樣的字符），它具有一個(gè)專屬的XxxSecurity類型的Security屬性。而這個(gè)XxxSecurity類型一般具有三個(gè)屬性：Mode表示采用的安全模式，而Transport和Message用于針對(duì)Transport和Message安全模式下的設(shè)置。

　　對(duì)于圍繞著綁定進(jìn)行的安全設(shè)置，我們首要的任務(wù)就是制定采用的安全模式。在安全模式確定之后，客戶端憑證的選擇決定了認(rèn)證方最終采用怎樣的認(rèn)證機(jī)制。接下來(lái)，我們就來(lái)談?wù)勧槍?duì)不各種常用的系統(tǒng)預(yù)定義綁定，安全模式和基于安全模式的客戶端憑證如何設(shè)置。先從BasicHttpBinding談起。

　　二、BasicHttpBinding支持的安全模式

　　下面的代碼片斷表示BasicHttpBinding安全相關(guān)應(yīng)用編程接口的定義，這和上面給出的“泛型綁定”的定義完全一致。通過(guò)Security屬性返回用于進(jìn)行針對(duì)BasicHttpBinding安全設(shè)置的類型為BasicHttpSecurity。BasicHttpSecurity的Mode、Transport和Message三種屬性的類型分別為BasicHttpSecurityMode、HttpTransportSecurity和BasicHttpMessageSecurity。

   1: public class BasicHttpBinding : Binding, IBindingRuntimePreferences

   2: {

   3:     //其他成員

   4:     public BasicHttpSecurity Security { get; set; }

   5: }

   6: public sealed class BasicHttpSecurity

   7: {

   8:     //其他成員

   9:     public BasicHttpSecurityMode    Mode { get; set; }

  10:     public HttpTransportSecurity    Transport { get; set; }

  11:     public BasicHttpMessageSecurity Message { get; set; }

  12: }

　　枚舉BasicHttpSecurityMode中定義了BasicHttpBinding支持的5中安全模式。其中None為默認(rèn)選項(xiàng)，表示并不采用任何安全機(jī)制，Transport、Message和TransportWithMessageCredential分別表示之前介紹的Transport、Message和Mixed安全模式。TransportWithMessageCredential表示“使用基于Message模式憑證的Transport模式”。由于Mixed安全模式通過(guò)Message模式實(shí)現(xiàn)對(duì)客戶端的認(rèn)證，所以要求客戶端采用基于Message模式的憑證。而除客戶端認(rèn)證的其他安全要素的實(shí)現(xiàn)則都是采用Transport模式。所以TransportWithMessageCredential在BasicHttpSecurityMode枚舉中的表示和我們講的Mixed模式從語(yǔ)義上講是一致的。TransportCredentialOnly是BasicHttpBinding所獨(dú)有的安全模式。它只提供針對(duì)于HTTP的客戶端認(rèn)證，并不能提供消息一致性和機(jī)密性的保證。

   1: public enum BasicHttpSecurityMode

   2: {

   3:     None,

   4:     Transport,

   5:     Message,

   6:     TransportWithMessageCredential,

   7:     TransportCredentialOnly

   8: }

　　三、基于Transport模式的客戶端憑證

　　HttpTransportSecurity用于進(jìn)行針對(duì)Transport模式下的安全設(shè)置。而通過(guò)ClientCredentialType屬性，我們可以設(shè)置客戶端憑證的類型。該屬性類型為HttpClientCredentialType枚舉，定義其中的六個(gè)枚舉值表示支持的六種基于Tranport模式的客戶端憑證類型。HttpTransportSecurity和HttpClientCredentialType相關(guān)定義如下。

   1: public sealed class HttpTransportSecurity

   2: {

   3:     //其他成員

   4:     public HttpClientCredentialType ClientCredentialType {get; set; }

   5: }

   6: public enum HttpClientCredentialType

   7: {

   8:     None,

   9:     Basic,

  10:     Digest,

  11:     Ntlm,

  12:     Windows,

  13:     Certificate

  14: }

　　定義在枚舉類型HttpClientCredentialType中的六種不同的客戶端用戶憑證類型體現(xiàn)了服務(wù)端針對(duì)客戶端不同的認(rèn)證方式：

• None：客戶端無(wú)需指定用戶憑證，即匿名認(rèn)證。此為默認(rèn)值；
• Basic：采用Basic認(rèn)證方式進(jìn)行客戶端認(rèn)證。在這種認(rèn)證方式下，客戶端需要提供有效的用戶名和密碼，但是僅僅采用較弱的方式對(duì)密碼進(jìn)行加密。所以當(dāng)且僅當(dāng)你確定客戶端和服務(wù)端之間的連接絕對(duì)安全的前提下，你才能用這種認(rèn)證方式；
• Digest：采用Digest認(rèn)證方式進(jìn)行客戶端認(rèn)證。Digest認(rèn)證提供與Basic一樣的認(rèn)證功能，但是在安全性上有所提升。主要體現(xiàn)并不是直接將用戶名和密碼直接進(jìn)行網(wǎng)絡(luò)傳輸，而是對(duì)其進(jìn)行哈希計(jì)算（MD5）得到一個(gè)哈希碼（此過(guò)程又稱為Message Digest），最終傳輸?shù)氖窃摴４a；
• Ntlm：表示使用基于NTLM方式的Windows集成認(rèn)證方式對(duì)客戶端進(jìn)行認(rèn)證；
• Windows：表示使用Windows集成認(rèn)證的方式對(duì)客戶端進(jìn)行認(rèn)證。如果能夠使用Kerberos，則直接采用Kerberos進(jìn)行認(rèn)證，否則才使用NTLM；
• Certificate：表示客戶端的身份通過(guò)一個(gè)X.509數(shù)字證書表示，服務(wù)端通過(guò)校驗(yàn)證書的方式來(lái)確定客戶端的真實(shí)身份。

　　無(wú)論是在進(jìn)行服務(wù)寄宿的時(shí)候?yàn)镾erviceHost添加終結(jié)點(diǎn)，還是在客戶端創(chuàng)建調(diào)用服務(wù)的終結(jié)點(diǎn)，都可以通過(guò)編程的方式來(lái)設(shè)置綁定的安全模式和客戶端用于憑證類型。如下面的代碼片斷所示，我們?yōu)锽asicHttpBinding設(shè)置了Transport安全模式，并將其客戶端憑證設(shè)置成Windows。由于所有基于HTTP的綁定都通過(guò)HTTPS來(lái)實(shí)現(xiàn)Transport安全，所以當(dāng)選擇Transport和TransportWithMessageCredential安全模式的情況下，終結(jié)點(diǎn)地址必須是一個(gè)HTTPS地址。

   1: using(ServiceHost host = new ServiceHost(typeof(CalculatorService)))

   2: {

   3: var binding = new BasicHttpBinding(BasicHttpSecurityMode.Transport);

   4:     binding.Security.Transport.ClientCredentialType =
 HttpClientCredentialType.Windows;

   5:     host.AddServiceEndpoint(typeof(ICalculator), binding,
 "//localhost/calculatorservice");

   6:     host.Open();

   7:     ...

   8: }

　　服務(wù)調(diào)用代碼：

   1: var binding = new BasicHttpBinding(BasicHttpSecurityMode.Transport);

   2: binding.Security.Transport.ClientCredentialType =
 HttpClientCredentialType.Windows;

   3: using (ChannelFactory<ICalculator> channelFactory =
 new ChannelFactory<ICalculator>
(binding, "//localhost/calculatorservice"))

   4: {

   5:     ICalculator calculator = channelFactory.CreateChannel();

   6:     double result = calculator.Add(1, 2);

   7:     ...

   8: }

　　對(duì)于包括客戶端憑證類型在內(nèi)的針對(duì)綁定的安全設(shè)置，我們還是推薦采用配置的方式。基于綁定的配置節(jié)中具有一個(gè)<security>的字節(jié)點(diǎn)，用于進(jìn)行安全相關(guān)的設(shè)置。采用的安全模式通過(guò)該節(jié)點(diǎn)的mode屬性設(shè)置。而給予Transport模式相關(guān)的設(shè)置則配置在<security>/<transport>配置節(jié)中，其中配置屬性clientCredentialType表示客戶端憑證類型。在下面的給出的配置片斷中，我為寄宿的服務(wù)添加了一個(gè)采用BasicHttpBinding的終結(jié)點(diǎn)，該綁定的模式被設(shè)置為Transport，并采用Certificate客戶端憑證類型。

   1: <system.serviceModel>  

   2:   <bindings>

   3:     <basicHttpBinding>

   4:       <binding name="transportBinding">

   5:         <security mode="Transport">

   6:    <transport clientCredentialType="Certificate"/>

   7:         </security>

   8:       </binding>      

   9:     </basicHttpBinding>

  10:   </bindings>

  11:   <services>

  12:  <service name="Artech.WcfServices.Services.CalculatorService">

  13:  <endpoint address="//Jinnan-PC/calculatorservice" 
binding="basicHttpBinding" bindingConfiguration="transportBinding"
 contract="Artech.WcfServices.Contracts.ICalculator" />

  14:     </service>

  15:   </services>

  16: </system.serviceModel>

　　四、基于Message模式的客戶端憑證

　　類型BasicHttpSecurity用于進(jìn)行針對(duì)于BasicHttpBinding關(guān)于Message安全模式的相關(guān)設(shè)置。你同樣可以通過(guò)它的ClientCredentialType屬性設(shè)置客戶端憑證類型，該屬性類型為System.ServiceModel.BasicHttpMessageCredentialType枚舉。定義在BasicHttpMessageCredentialType中的兩個(gè)枚舉值（UserName和Certificate）表示支持的兩種客戶端憑證類型，它們分別代表基于用戶名/密碼的憑證和針對(duì)X.509證書的憑證。在默認(rèn)的情況下采用用戶名/密碼的憑證。BasicHttpMessageSecurity和BasicHttpMessageCredentialType相關(guān)定義如下面的代碼片斷所示。

   1: public sealed class BasicHttpMessageSecurity

   2: {

   3:   public BasicHttpMessageCredentialType
 ClientCredentialType { get; set; }

   4: }

   5: public enum BasicHttpMessageCredentialType

   6: {

   7:     UserName,

   8:     Certificate

   9: }

　　關(guān)于上述的兩種客戶端憑證，BasicHttpMessageCredentialType.UserName只能用在Mixed模式下。當(dāng)你選擇了Message模式，則只能選擇BasicHttpMessageCredentialType. Certificate。 WCF為什么會(huì)具有如此一個(gè)限制，你會(huì)在后續(xù)文章中找到答案。舉個(gè)例子，我通過(guò)如下一段代碼對(duì)服務(wù)CalculatorService進(jìn)行寄宿，并采用了一個(gè)采用Message模式的BasicHttpBinding。

   1: using (ServiceHost host =
 new ServiceHost(typeof(CalculatorService)))

   2: {

   3:     var binding = new BasicHttpBinding
(BasicHttpSecurityMode.Message);

   4:     host.AddServiceEndpoint(typeof(ICalculator), 
binding, "//localhost/calculatorservice");

   5:     host.Open();

   6:     ...

   7: }

　　當(dāng)ServiceHost被開(kāi)啟的時(shí)候，如下圖所示的InvalidOperationException異常被拋出來(lái)，并提示“BasicHttpBinding綁定要求 BasicHttpBinding.Security.Message.ClientCredentialType 等效于安全消息的 BasicHttpMessageCredentialType.Certificate 憑據(jù)類型。為 UserName 憑據(jù)選擇Transport 或 TransportWithMessageCredential 安全性”。實(shí)際上這個(gè)異常消息不太正確，因?yàn)門ranport模式下根本就不存在UserName憑證類型。

　　在基于綁定的配置節(jié)中，Message模式相關(guān)選項(xiàng)通過(guò)<security>/<message>配置節(jié)進(jìn)行設(shè)置。在該配置節(jié)中，clientCredentialType屬性用于設(shè)置客戶端憑證類型。在下面的配置片斷中，我為寄宿的服務(wù)添加了兩個(gè)采用BasicHttpBinding的終結(jié)點(diǎn)。其中第一個(gè)終結(jié)點(diǎn)的綁定為Message模式，并采用Certificate憑證。另一個(gè)終結(jié)點(diǎn)綁定為TransportWithMessageCredential模式，采用UserName憑證。為了保證服務(wù)寄宿的成功，我們還必須通過(guò)服務(wù)行為的形式為服務(wù)指定一個(gè)X.509證書作為服務(wù)憑證。這實(shí)際上涉及到了服務(wù)認(rèn)證的話題，我們將本節(jié)后續(xù)部分進(jìn)行介紹。

   1: <system.serviceModel>

   2:   <behaviors>

   3:     <serviceBehaviors>

   4:       <behavior name="serviceCertificateBehavior">

   5:         <serviceCredentials>

   6:           <serviceCertificate findValue="Jinnan-PC" 
x509FindType="FindBySubjectName" />

   7:         </serviceCredentials>

   8:       </behavior>

   9:     </serviceBehaviors>

  10:   </behaviors>

  11:   <bindings>

  12:     <basicHttpBinding>

  13:       <binding name="messageBinding">

  14:         <security mode="Message">

  15:           <message clientCredentialType="Certificate"/>

  16:         </security>

  17:       </binding>

  18:       <binding name="transportWithMessageCredentialBinding">

  19:         <security mode="TransportWithMessageCredential">

  20:           <message clientCredentialType="UserName" />

  21:         </security>

  22:       </binding>

  23:     </basicHttpBinding>

  24:   </bindings>

  25:   <services>

  26:     <service behaviorConfiguration="serviceCertificateBehavior" 
name="Artech.WcfServices.Services.CalculatorService">

  27:       <endpoint address="//Jinnan-PC/calculatorservice1"
 binding="basicHttpBinding"

  28:         bindingConfiguration="messageBinding"
 contract="Artech.WcfServices.Contracts.ICalculator" />

  29:       <endpoint address="//Jinnan-PC/calculatorservice2" 
binding="basicHttpBinding"

  30:  bindingConfiguration="transportWithMessageCredentialBinding" 
contract="Artech.WcfServices.Contracts.ICalculator" />

  31:     </service>

  32:   </services>

  33: </system.serviceModel>