Question

I’ve got a WCF service that is to be called by an application hosted on the web server (for the short-medium term, we’ll only need a single web server so disregard scalability issues)

The web server serves a public website. at example.com

The WCF service exposes calls which amongst other things run jobs and provide certain admin functionality not supported by the web model eg long running database operations.

The WCF service has to be hosted inside the web site as it uses compatibility mode to take advantage of the Asp.Net http(s) pipeline – specifically, the service can generate emails and the emails are templated using MVC. One side-effect of this is that the call has to use the publicly visible hostname eg https://example.com/JobService.svc so that links in emails point to example.com as opposed to localhost or similar.

Obviously, I don’t want the general public to be able to kick off jobs/admin tasks so I want to secure the WCF service.

I can only use https as opposed to net.tcp or similar for the binding thanks to relying on the Asp.net http pipeline.

I have to bind to the publicly accessible IP address to be able to use the proper hostname (unless someone knows a way around this?)

I can’t use kerberos/NTLM as the server isn’t on a domain (and NTLM is weak anyway)

I can’t use certificates as it complains:

The SSL settings for the service 'SslRequireCert' does not match those of the IIS 'None'.

NB: I don’t quite understand this as the website itself is only served via https. http simply returns a redirect to the same page via https.

(An interesting issue I’m having is that although the mex is served via https, the URLs inside the WSDL use http. I’m assuming this is a side-effect of not being able to set up TLS properly on my service so it thinks it’s http even though it also responds on https)

So, I’m running out of ideas for how to secure my service. I could, of course, from within the service itself examine the request and determine if it comes from an IP used by the current server – but this feels very nasty and I’m effectively ignoring the work of experts and trying to put something in its place – Not a very good place to start.

Can anyone suggest a way to limit access to this service to processes on the local machine?

I’ve attached my current config below. (This is currently giving me the certificate error mentioned above)

<system.serviceModel>
    <bindings>
        <basicHttpBinding>
            <binding name="WebJobServiceHTTPBinding" openTimeout="00:10:00"
                sendTimeout="00:10:00">
                <security mode="Transport">
                    <transport clientCredentialType="Certificate" />
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true"
                               aspNetCompatibilityEnabled="true">
        <serviceActivations>
            <add relativeAddress="WebJob.svc"
                 service="MyApp.WebJobService"
                 factory="MyApp.WCFDIServiceHostFactory" />
        </serviceActivations>
    </serviceHostingEnvironment>
    <services>
        <service behaviorConfiguration="WebJobServiceBehavior" name="MyApp.WebJobService">
            <endpoint address="" binding="basicHttpBinding" bindingConfiguration="WebJobServiceHTTPBinding"
                name="HTTPEndpoint" contract="MyApp.JobService.Common.IWebJobService" />
        </service>
    </services>
    <standardEndpoints>
        <mexEndpoint>
            <standardEndpoint name="WebJobServiceMex" />
        </mexEndpoint>
    </standardEndpoints>
    <behaviors>
        <serviceBehaviors>
            <behavior name="WebJobServiceBehavior">
                <serviceMetadata httpGetEnabled="true" />
                <serviceDebug includeExceptionDetailInFaults="true" />
                <serviceCredentials>
                    <serviceCertificate findValue="[Thumbprint of x509 cert used by website for SSL]"
                        storeName="Root" x509FindType="FindByThumbprint" />
                </serviceCredentials>
            </behavior>
        </serviceBehaviors>
    </behaviors>
</system.serviceModel>

Answer 1

In the end, I was forced to implement my own Authentication system. This was relatively simple as authenticatio implied authorization – ie no permission levels. That said, I’m still unhappy at the solution and will change it if another option presents itself.