Section 10.11. No Security

10.11. No Security

In this last scenario, your application turns off security completely. The service does not rely on any transfer security, and it does not authenticate or authorize its callers. Obviously, such a service is completely exposed and you generally need a very good business justification for relinquishing security. You can accept any number of clients, and both an Internet and an intranet service can be configured for No Security.

10.11.1. Unsecuring the Bindings

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), but you have no reason to ever use this mode with the WSFederationHttpBinding since the only reason for choosing it in the first place is the need for federated security.

Configuring the allowed bindings is similar to the previous scenarios, except the security mode is set to no transfer security; for example, by using MessageCredentialType.None in the case of NetTcpBinding:

 NetTcpBinding binding = new NetTcpBinding(SecurityMode.None); 

Or when using a config file:

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

10.11.2. Authentication

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

10.11.3. Authorization

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 have WCF install a generic principal with a blank identity.

10.11.4. Identity Management

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 will return null. Table 10-8 shows the identities in this scenario.

Table 10-8. Identity management in the No Security scenario

Identity	Type	Value	Authenticated
Thread Principal	GenericIdentity	-	No
Security Context Primary	-	-	-
Security Context Windows	-	-	-

10.11.4.1. Impersonation

Because the clients are anonymous, the service cannot impersonate any of its clients.

10.11.5. Callbacks

Unlike all the previous scenarios, in the absence of transfer security, callback comes 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 either in 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.