Introduction:
In this article,i am going to explain about how to configure a security in wcf service.

Main:
The binding and behaviors in WCF represent the main entry point for the configuration subsystem and the policies that affect the services at runtime. This rich and configurable environment enables you to create security policies and enforce them at runtime in your services. Choosing the right security schema and policies for your services should only be a matter of determining the initial requirements in terms of message protection, authentication, and authorization.

The bindings, in addition to specifying the communication protocol and encoding for the services, will also allow you to configure the message protection settings and the authentication schema. On the other hand, the behaviors allow you to specify other kinds of security settings such as client and service credentials, credential validators, authorization policies, and managers, to name a few.

The binding selection also influences the available configuration options for the service security policy. For instance, the BasicHttp binding only supports legacy web service protocols, and therefore only transport security can be configured with this binding.

All the configuration settings in the bindings and behaviors can be set either as programming against the configuration object model or through a .NET configuration section.

To avoid bad practices when configuring security, the WCF team restricts the number of security settings that can be used in the configuration section. Username and password credentials represent a good example of this. It would not be a good idea to hardcode some passwords in a configuration file, and for that reason, they are only available in the configuration object model.

To simplify the configuration process even more, all the bindings come with a pre-defined configuration schema that satisfies the most common scenarios. In that way, as long as you do not tweak specific settings, WCF tries to use the default security schema.

Default security Settings,

WsHttpBinding
Message Security with Windows Authentication (NTLM or Kerberos)

BasicHttpBinding
No Security

WsFederationHttpBinding
Message Security with Federated Authentication (Issue Tokens)

NetTcpBinding
Transport Security with Windows Authentication (NTLM or Kerberos)

NetNamedPipeBinding
Transport Security with Windows Authentication (NTLM or Kerberos)

NetMsmqBinding
Transport Security with Windows Authentication (NTLM or Kerberos)

WCF supports five types of identities for a service. Their uses depend on the scenario you want to implement and the security requirements that the services demand. All the possible values for the identity types are,

Domain Name System (DNS)

This type of identity is valid for X509 certificates or Windows accounts. The value specified in this element must match the Windows account name or the certificate subject name. In case of certificates, as long as the subject name does not change, the identity check is still valid.

Certificate

This type specifies an X509 certificate encoded as Base64. As you need to encode the entire certificate, which includes unique information such as the certificate thumbprint, this identity type represents a more precise alternative to the DNS identity.

A downside is that you need to hardcode the complete certificate representation in the WCF configuration.

Certificate Reference

Pretty similar to the previous option. The main difference is that this identity type enables you to specify a certificate name and the location in the certificate store rather than hard coding the credential representation. It requires a previous deployment of the certificate in the Windows certificate store.

RSA

This identity type specifies a certificate RSA key. This option enables you to specifically restrict authentication to a single certificate based on a certificate key. As the certificate option, the key representation must be specified in Base64 encoding.

User Principal Name (UPN)

This identity type is specific to Windows authentication and specifies the UPN that the service is running under. This option is used by default when the service process is not running under of one the system accounts. In other words, it ensures that the service is running under a specific Windows account, which can be either the current logged-on user or any user account.

Service Principal Name (SPN)

This identity type is also specific to Windows authentication and specifies the SPN associated with the account that is running the service process. This option is used by default when the service process is running under the system accounts LocalService, LocalSystem, or NetworkService.

WCF can automatically negotiate the value for this identity when the service is configured with Windows authentication and the negotiateServiceCredential for message security is set to true.

Conclusion:
Hope this helps,
Happy coding.