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. Both Internet and intranet services can be configured for no security, and they can accept any number of clients.
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
.
3.144.15.154