To turn off security, you need to set the transfer security mode to None. This will also avoid storing any client credentials in the message. All bindings support no transfer security (see Table 10-1).

Configuring the allowed bindings is done similarly to the previous scenarios, except the transfer security mode is set to None. For example, here's how to configure the NetTcpBinding programmatically:

NetTcpBinding binding = new NetTcpBinding(SecurityMode.None);

And here's how to do this using a config file:

<bindings>
   <netTcpBinding>
      <binding name = "NoSecurity">
         <security mode = "None"/>
      </binding>
   </netTcpBinding>
</bindings>

No client authentication is done in this scenario, and the client does not need to provide any credentials to the proxy. Nor does the client ever authenticate the service.

Since the clients are anonymous (and unauthenticated), authorization and role-based security are precluded. WCF will automatically set the PrincipalPermissionMode property to PrincipalPermissionMode.None to install a generic principal with a blank identity.

The identity associated with the principal object is a GenericIdentity with a blank username. That identity is considered unauthenticated. Unlike all the previous scenarios, in the no security scenario, the operation has no security call context, and the ServiceSecurityContext.Current returns null. Table 10-8 shows the identities in this scenario.

Unlike in all the previous scenarios, in the absence of transfer security, callbacks come in under the client's own identity. The principal identity will be set to an instance of WindowsIdentity with the client's username. The callback will be authenticated, but there is no point in either impersonation or using role-based security since the client will only be authorizing itself. In addition, the security call context of the callback will be set to null.