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.
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>
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.
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.
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.
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
.