Transport Security Protection Level
This article explains about the how to configure the service with Transport security settings and what are the protection level available.
When configure transfer security for Transport security, not all bindings support all client credential type
Below table list client credential for different binding
| Name |
None |
Windows |
Username |
Certificate |
| BasicHttpBinding |
Yes(default) |
Yes |
Yes |
Yes |
| NetTcpBinding |
Yes |
Yes(default) |
No |
Yes |
| NetNamedPipeBinding |
No |
Yes(default) |
No |
No |
| WsHttpBinding |
Yes |
Yes(default) |
Yes |
Yes |
| WsDualHttpBinding |
N/A |
N/A |
N/A |
N/A |
| NetMsmqHttpBinding |
Yes |
Yes(default) |
No |
Yes |
Below diagram explain about how set the client credential in configuration file 
While developing Intranet application, it is good to go with Transportnode for transfer security because calls are invariably point-to-point.
In NetTcpBinding/NetNamedPipeBinding/NetMsmqBinding supports three level of protection to transfer message 
>
- None: Message does not get protected while transfer from client and service
- Signed: this protection level make sure that message is received from authenticated user, but it message can be tampered by any third party.
- Encrypted and Signed: This level makes sure that message is received from authenticated user and it also encrypts the message
Tips!
- Always create the service with Interface->Implementation format, mention the contract in Interface.
- Define the service in Class library and refer the class library in Host project. Don’t use service class in host project.
- Change the instance mode to per call as default.
- Always catch exception using try/catch block and throw exception using FaultException < T >.
- Logging and Include exception should be enable while compiling the project in debug mode. While in production deployment disable the logging and Include exception details.
|