How to programmatically configure SSL for WCF Services

One of the issues with WCF is that is heavily depends on declarative configuration. In case of the SSL protocol, a basic ASP.NET WebService supports it “out-of-the-box” if the web server supports it. But a WCF service configured for noSSL calls will not accept SSL calls without an extra configuration. This article describes the issue and the ability to configure the service programmatically to lower the risk of misconfiguration.

Static configuration of WCF endpoints

Let’s start from a basic configuration of a service configured for noSSL calls:

<system.serviceModel>
    <bindings>
        <basicHttpBinding>
            <binding name="basicHttpBinding1">
                <security mode="None" />
            </binding>
        </basicHttpBinding>
    </bindings>
    <behaviors>
        <serviceBehaviors>
            <behavior name="SilverlightApplication13.Web.Service2Behavior">
                <serviceMetadata httpGetEnabled="true" />
                <serviceDebug includeExceptionDetailInFaults="false" />
            </behavior>
        </serviceBehaviors>
    </behaviors>
    <services>
        <service behaviorConfiguration="SilverlightApplication13.Web.Service2Behavior"
         name="SilverlightApplication13.Web.Service2">
            <endpoint address="" binding="basicHttpBinding" bindingConfiguration="basicHttpBinding1" contract="SilverlightApplication13.Web.Service2">
            </endpoint>
            <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
        </service>
    </services>
</system.serviceModel>

As you can see I have a single endpoint with security mode set to None which corresponds to noSSL mode. With such static configuration the SSL is not a problem. You just define an extra endpoint with proper settings (mode set to Transport):

<system.serviceModel>
    <bindings>
        <basicHttpBinding>
            <binding name="basicHttpBinding1">
                <security mode="None" />
            </binding>
            <binding name="basicHttpBinding2">
                <security mode="Transport" />
            </binding>
        </basicHttpBinding>
    </bindings>
    <behaviors>
        <serviceBehaviors>
            <behavior name="SilverlightApplication13.Web.Service2Behavior">
                <serviceMetadata httpGetEnabled="true" />
                <serviceDebug includeExceptionDetailInFaults="false" />
            </behavior>
        </serviceBehaviors>
    </behaviors>
    <services>
        <service behaviorConfiguration="SilverlightApplication13.Web.Service2Behavior"
         name="SilverlightApplication13.Web.Service2">
            <endpoint address="" binding="basicHttpBinding" 
                bindingConfiguration="basicHttpBinding1" 
                contract="SilverlightApplication13.Web.Service2">
            </endpoint>
            <endpoint address="" binding="basicHttpBinding" 
                bindingConfiguration="basicHttpBinding2" 
                contract="SilverlightApplication13.Web.Service2">
            </endpoint>
            <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
        </service>
    </services>
</system.serviceModel>

However, there are two issues here.

First, note that both endpoints has empty value of address attribute. This won’t work. The second endpoint’s address has to be manually configured. For example:

<services>
    <service behaviorConfiguration="SilverlightApplication13.Web.Service2Behavior"
     name="SilverlightApplication13.Web.Service2">
        <endpoint address="" binding="basicHttpBinding" 
            bindingConfiguration="basicHttpBinding1" 
            contract="SilverlightApplication13.Web.Service2">
        </endpoint>
        <endpoint address="https://myhost.com/service1.svc" binding="basicHttpBinding" 
            bindingConfiguration="basicHttpBinding2" 
            contract="SilverlightApplication13.Web.Service2">
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
    </service>
</services>

It means that everytime you expose your service under different address, you have to reconfigure it in web.config.

But having two endpoints with different bindings stops your service from working with the Visual Studio Integrated Web Server since it does not support the SSL protocol (you’ll get the exception from the integrated webserver saying that SSL is not supported).

The simplest solution for both issues is to have a two sets of configuration files. One used with the development environment would have a single endpoint for noSSL calls. The other one used in a production environment. However, having few or few dozens of services means that there’s a risk of the misconfiguration, revealed only in the runtime.

Creating endpoints dynamically

The other option however would be to create endpoints dynamically depending on the environment. This way no static configuration is required and the service would expose a single noSSL endpoint when working with the Integrated WebServer and two endpoints (SSL/noSSL) when deployed onto the IIS.

I have found few articles on the dynamic configuration of self-hosted WCF services, however it has been much harder to find a way to do it with the IIS.

To have your service configured dynamically, you start with the *.svc file to change the way the IIS initializes your service:

<%@ ServiceHost Language="C#" Debug="true" 
    Service="SilverlightApplication13.Web.Service2" CodeBehind="Service2.svc.cs" %>

and you change this to point to a factory class responsible for creating instances of your service:

<%@ ServiceHost Language="C#" Debug="true" 
    Factory="SilverlightApplication13.Web.Service1Factory" CodeBehind="Service1.svc.cs" %>

and you provide the implementation of the factory:

public class Service1Factory : ServiceHostFactory
{
     public override ServiceHostBase CreateServiceHost( string constructorString, Uri[] baseAddresses )
     {
         ServiceHost serviceHost = new ServiceHost( typeof( Service1 ), baseAddresses );

         // create the noSSL endpoint
         serviceHost.AddServiceEndpoint( typeof( Service1 ), new BasicHttpBinding(), "" );

         // create SSL endpoint
         if ( ExposeAsSSL )
             serviceHost.AddServiceEndpoint( 
                typeof( Service1 ), 
                new BasicHttpBinding( BasicHttpSecurityMode.Transport ) , 
                baseAddresses[0].ToString().Replace( "http", "https" ) );

         // Enable HttpGet for the service
         ServiceMetadataBehavior metadata = new ServiceMetadataBehavior();
         metadata.HttpGetEnabled = true;
         serviceHost.Description.Behaviors.Add( metadata );

         return serviceHost;
     }
}

[ServiceContract( Namespace="http://www.test.com/test" )]
[ServiceBehavior( 
    InstanceContextMode = InstanceContextMode.Single, 
    ConcurrencyMode = ConcurrencyMode.Multiple )]      //please refer to the docs for more info on these values
public class Service1 
{
    [OperationContract]
    public string DoWork( string Param )
    {
        return Param;
    }
}

Note that there’s just a single ExposeAsSSL variable which has to be configured somehow but the risk of misconfiguration is much lower.

System.Windows.Forms.Timer vs System.Timers.Timer/System.Threading.Timer

There is an obvious difference between System.Windows.Forms.Timer and System.Timers[System.Threading].Timer – the former is handled with Win32’s WM_TIMER message and thus it needs a message loop which usually means you need a Windows application.

But there’s also a much less obvious difference – and this difference is the reason to write this entry.

Suppose you set your Windows.Forms timer to 50 miliseconds and then a single Tick lasts a little bit longer:

// execute the Tick every 50 miliseconds

private void timer1_Tick( object sender, EventArgs e )

{

     this.richTextBox1.Text += DateTime.Now.ToString() + Environment.NewLine;

     // but a single Tick lasts longer

     Thread.Sleep( 1000 );

}

What happens then? You see, a WM_TIMER message is constrained by the system so that is never occurs too often. It means that the message queue will not be flooded with extra messages and you are safe. In the above scenario, the RichTextBox would be updated once for a second, even if the timer is set to launch every 50 miliseconds.

But the case is completely different with the two latter timers! The operating system launches a new thread with every tick so that you are not safe from having multiple ticks running in the same time.

static void Main( string[] args )

{

    System.Threading.Timer t = new Timer( timer_callback, null, 0, 50 );           

    while ( true ) { }

}

static void timer_callback( object state )

{

    Console.WriteLine( DateTime.Now.ToString() );

    Thread.Sleep( 1000 );

}

Run the above code snippet to see that the console is actually flooded with messages arriving independently much ofter than you’d expect. This time it’s important then to manually handle the flooding:

static void Main( string[] args )

{

    System.Threading.Timer t = new Timer( timer_callback, null, 0, 50 );           

    while ( true ) { }

}

static bool worksNow;

static void timer_callback( object state )

{

    // exit if in the middle of action 

    if ( worksNow ) return;

    try

    {

        // disable temporarily

        worksNow = true;

        Console.WriteLine( DateTime.Now.ToString() );

        Thread.Sleep( 1000 );

    }

    finally

    {

        // make sure that the handler is always reenables

        worksNow = false;

    }

}

There’s still a small issue with such approach. This time, when the timer interval is only a fraction smaller than the time of the action, every second tick of the timer will exit because of the value true of the guarding worksNow variable but then there will be a long period of inactivity before next timer’s tick. You’d rather like the timer to resume the work immediately after the handler completes.

static void Main( string[] args )

{

    System.Timers.Timer t = new System.Timers.Timer( 50 );

    t.Elapsed += new System.Timers.ElapsedEventHandler(t_Elapsed);

    t.Start();

    while ( true ) { }

}

static void t_Elapsed( object sender, System.Timers.ElapsedEventArgs e )

{

    System.Timers.Timer Timer = 

        (System.Timers.Timer)sender;

    try

    {

        // disable temporarily

        Timer.Stop();

        Console.WriteLine( DateTime.Now.ToString() );

        Thread.Sleep( 1000 );

    }

    finally

    {

        // make sure that the handler is always reenables

        Timer.Start();

    }

}

The only subtle issue here is that, as you’ve probably noticed, there does not seem to be an easy way to stop/start System.Threading.Timer, so I had to switch to System.Timers.Timer.

Complete list of different timers with their profiles is available on the MSDN Magazine.