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

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

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

   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: }

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

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

　　二、BasicHttpBinding支持的安全模式

　　下面的代碼片斷表示BasicHttpBinding安全相關(guān)應(yīng)用編程接口的定義，這和上面給出的“泛型綁定”的定義完全一致。通過Security屬性返回用于進行針對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為默認選項，表示并不采用任何安全機制，Transport、Message和TransportWithMessageCredential分別表示之前介紹的Transport、Message和Mixed安全模式。TransportWithMessageCredential表示“使用基于Message模式憑證的Transport模式”。由于Mixed安全模式通過Message模式實現(xiàn)對客戶端的認證，所以要求客戶端采用基于Message模式的憑證。而除客戶端認證的其他安全要素的實現(xiàn)則都是采用Transport模式。所以TransportWithMessageCredential在BasicHttpSecurityMode枚舉中的表示和我們講的Mixed模式從語義上講是一致的。TransportCredentialOnly是BasicHttpBinding所獨有的安全模式。它只提供針對于HTTP的客戶端認證，并不能提供消息一致性和機密性的保證。

   1: public enum BasicHttpSecurityMode

   2: {

   3:     None,

   4:     Transport,

   5:     Message,

   6:     TransportWithMessageCredential,

   7:     TransportCredentialOnly

   8: }

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

　　HttpTransportSecurity用于進行針對Transport模式下的安全設(shè)置。而通過ClientCredentialType屬性，我們可以設(shè)置客戶端憑證的類型。該屬性類型為HttpClientCredentialType枚舉，定義其中的六個枚舉值表示支持的六種基于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ù)端針對客戶端不同的認證方式：

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

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

　　對于包括客戶端憑證類型在內(nèi)的針對綁定的安全設(shè)置，我們還是推薦采用配置的方式。基于綁定的配置節(jié)中具有一個<security>的字節(jié)點，用于進行安全相關(guān)的設(shè)置。采用的安全模式通過該節(jié)點的mode屬性設(shè)置。而給予Transport模式相關(guān)的設(shè)置則配置在<security>/<transport>配置節(jié)中，其中配置屬性clientCredentialType表示客戶端憑證類型。在下面的給出的配置片斷中，我為寄宿的服務(wù)添加了一個采用BasicHttpBinding的終結(jié)點，該綁定的模式被設(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用于進行針對于BasicHttpBinding關(guān)于Message安全模式的相關(guān)設(shè)置。你同樣可以通過它的ClientCredentialType屬性設(shè)置客戶端憑證類型，該屬性類型為System.ServiceModel.BasicHttpMessageCredentialType枚舉。定義在BasicHttpMessageCredentialType中的兩個枚舉值（UserName和Certificate）表示支持的兩種客戶端憑證類型，它們分別代表基于用戶名/密碼的憑證和針對X.509證書的憑證。在默認的情況下采用用戶名/密碼的憑證。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模式下。當你選擇了Message模式，則只能選擇BasicHttpMessageCredentialType. Certificate。 WCF為什么會具有如此一個限制，你會在后續(xù)文章中找到答案。舉個例子，我通過如下一段代碼對服務(wù)CalculatorService進行寄宿，并采用了一個采用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: }

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

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

   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>