Best practices in WCF: Security, hosting and error handling guidelines

WCF (Windows Communication Foundation) is a secure, reliable, and scalable messaging platform for developing services in .Net. This is the second part in the series of articles on WCF best practices. In the first part of this series, we explored the WCF service design and performance guidelines and the recommended best practices. In this part, we’ll discuss the best practices and strategies in error handling, deployment, and security in WCF.

Best practices in WCF hosting and security

The four major points that you should consider when implementing security for your WCF services include: authentication, authorization, integrity, and confidentiality. If you are hosting your WCF service in IIS or in a Windows Service, you should use the least privileged account. Note that it is a recommended practice to host your WCF service in IIS. For WCF services that need to execute in an intranet environment, it is a good practice to use Windows authentication. You can take advantage of membership providers when you would like to implement an authentication mechanism that needs user credentials.

You should enable WCF Audit and Message Logs to retrieve audit information for monitoring your WCF service. WCF Audit helps you to log the security events of your WCF service — you can use the event viewer to view the security log. The following code snippet illustrates how you can turn on WCF Audit:

 <behaviors>

      <serviceBehaviors>

        <behavior>

           <serviceSecurityAudit auditLogLocation="Security" suppressAuditFailure="True" serviceAuthorizationAuditLevel="SuccessOrFailure"                       messageAuthenticationAuditLevel="SuccessOrFailure"/>

        </behavior>

      </serviceBehaviors>

 </behaviors>

You can enable message logging in WCF to log incoming messages for your WCF service using the following code snippet:

<diagnostics>

    <messageLogging logEntireMessage="True"></messageLogging>

</diagnostics>

You should not use temporary certificates to implement security when deploying WCF services in the production environment. Again, I would always prefer to use IIS as a hosting platform to host a WCF service unless you need to use some transport protocol that IIS doesn’t provide support for. You should host WCF service on IIS so that you can leverage IIS features related to security like authentication, certificates, etc. When hosting your WCF service in IIS enable SSL to prevent any phishing attacks. You may also take advantage of OAuth for implementing token based authorization for securing your WCF service.

WCF provides a standard set of bindings — you can use NetTcpBinding if you would like to use TCP communication that cross machine boundaries. NetTcpBinding is secure and message packets are signed and encrypted by default. You can also use WSHttpBinding to establish a secure session of communication. WSFederationHttpBinding is a good choice if you would like to implement secure communication in federated security scenerios. Each of the binding types supported in WCF can have the following security modes: None, Transport, Message, Both, TransportWithMessageCredential, and TransportCredentialOnly.

Transport and message security in WCF

You can secure the communication between your WCF service and client by using either Transport Security or Message Security. While the former is used to enforce security at the transport level, the latter is used to encrypt the message that is passed between the WCF server and the client. Note that the wsHttpBinding in WCF supports Message Security by default.

The following code snippet illustrates how you can turn Transport Security on using the configuration file of your WCF service.

<bindings>

       <wsHttpBinding>

            <binding>

                 <security mode="Transport"></security>

            </binding>

       </wsHttpBinding>

</bindings>

If you would like to use Message Security, use the following statement instead.

Error Handling

When using WCF in your service layer, you should handle exceptions properly so that the service consumer is communicated with the appropriate error message when an exception occurs. You can write exception blocks to handle runtime errors that occur in your WCF services. Handling exceptions in WCF is a bit tricky though primarily because you are constrained to sending .Net objects over the wire and your WCF service can only send out serialized data. You can actually handle exceptions in WCF in one of these three ways:

• FaultException — You can leverage fault exceptions in WCF to transmit user friendly error messages when exceptions occur in your WCF service methods. Fault exceptions are thrown by a WCF service when an exception occurs at runtime.
• IErrorHandler — you can take advantage of this interface to handle WCF exceptions globally.
• Using returnUnknownExceptionsAsFaults attribute — You can set the returnUnknownExceptionsAsFaults attribute to “True” in the service behavior to ensure that your service method can raise an exception as a SOAP fault automatically.

You should include exception details in debug builds only. You should never disclose the stack trace or exception details for WCF services hosted in the production environments — it is always a recommended practice to take advantage of Fault Contracts to transmit custom error messages that might occur in your WCF service.