We're in
the process of delivering an enabling project to expose on-premise WCF services securely to Internet consumers.
The Azure Service Bus Relay is doing
the clever stuff, we register our on-premise service with Azure, consumers call into our .servicebus.windows.net namespace, and their requests are relayed and serviced on-premise. In theory it's all wonderfully simple; by using
the relay we get lots of protocol options, free HTTPS and load balancing, and by integrating to ACS we get plenty of security options. Part of our delivery is a suite of sample consumers for
the service - .NET, jQuery, PHP - and this set of posts will cover setting up
the service and
the consumers. Part 1: Exposing
the on-premise service In theory, this is ultra-straightforward. In practice, and on a dev laptop it is - but in a corporate network with firewalls and proxies, it isn't, so we'll walkthrough some of
the pitfalls. Note that I'm using
the "old" Azure portal which will soon be out of date, but
the new shiny portal should have
the same steps available and be easier to use. We start with a simple WCF service which takes a string as input, reverses
the string and returns it.
The Part 1 version of
the code is on GitHub here: on GitHub here: IPASBR Part 1. Configuring Azure Service Bus Start by logging into
the Azure portal and registering a Service Bus namespace which will be our endpoint in
the cloud. Give it a globally unique name, set it up somewhere near you (if you’re in Europe, remember Europe (North) is Ireland, and Europe (West) is
the Netherlands), and enable ACS integration by ticking "Access Control" as a service: Authenticating and authorizing to ACS When we try to register our on-premise service as a listener for
the Service Bus endpoint, we need to supply credentials, which means only trusted service providers can act as listeners. We can use
the default "owner" credentials, but that has admin permissions so a dedicated service account is better (Neil Mackenzie has a good post On Not Using owner with
the Azure AppFabric Service Bus with lots of permission details). Click on "Access Control Service" for
the namespace, navigate to Service Identities and add a new one. Give
the new account a sensible name and description: Let ACS generate a symmetric key for you (this will be
the shared
secret we use in
the on-premise service to authenticate as a listener), but be sure to set
the expiration date to something usable.
The portal defaults to expiring new identities after 1 year - but when your year is up *your identity will expire without warning* and everything will stop working. In production, you'll need governance to manage identity expiration and a process to make sure you renew identities and roll new keys regularly.
The new service identity needs to be authorized to listen on
the service bus endpoint. This is done through claim mapping in ACS - we'll set up a rule that says if
the nameidentifier in
the input claims has
the value serviceProvider, in
the output we'll have an action claim with
the value Listen. In
the ACS portal you'll see that there is already a Relying Party Application set up for ServiceBus, which has a Default rule group. Edit
the rule group and click Add to add this new rule:
The values to use are: Issuer: Access Control Service Input claim type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier Input claim value: serviceProvider Output claim type: net.windows.servicebus.action Output claim value: Listen When your service namespace and identity are set up, open
the Part 1 solution and put your own namespace, service identity name and
secret key into
the file AzureConnectionDetails.xml in Solution Items, e.g: <azure namespace="sixeyed-ipasbr"> <!-- ACS credentials for
the listening service (Part1):--> <service identityName="serviceProvider" symmetricKey="nuR2tHhlrTCqf4YwjT2RA2BZ/+xa23euaRJNLh1a/V4="/> </azure> Build
the solution, and
the T4 template will generate
the Web.config for
the service project with your Azure details in
the transportClientEndpointBehavior: <behavior name="SharedSecret"> <transportClientEndpointBehavior credentialType="SharedSecret"> <clientCredentials> <sharedSecret issuerName="serviceProvider" issuerSecret="nuR2tHhlrTCqf4YwjT2RA2BZ/+xa23euaRJNLh1a/V4="/> </clientCredentials> </transportClientEndpointBehavior> </behavior> , and your service namespace in
the Azure endpoint: <!-- Azure Service Bus endpoints --> <endpoint address="sb://sixeyed-ipasbr.servicebus.windows.net/net" binding="netTcpRelayBinding" contract="Sixeyed.Ipasbr.Services.IFormatService" behaviorConfiguration="SharedSecret"> </endpoint>
The sample project is hosted in IIS, but it won't register with Azure until
the service is activated. Typically you'd install AppFabric 1.1 for Widnows Server and set
the service to auto-start in IIS, but for dev just navigate to
the local REST URL, which will activate
the service and register it with Azure. Testing
the service locally As well as an Azure endpoint,
the service has a WebHttpBinding for local REST access: <!-- local REST endpoint for internal use --> <endpoint address="rest" binding="webHttpBinding" behaviorConfiguration="RESTBehavior" contract="Sixeyed.Ipasbr.Services.IFormatService" /> Build
the service, then navigate to: http://localhost/Sixeyed.Ipasbr.Services/FormatService.svc/rest/reverse?string=abc123 - and you should see
the reversed string response: If your network allows it, you'll get
the expected response as before, but in
the background your service will also be listening in
the cloud. Good stuff! Who needs network security? Onto
the next post for consuming
the service with
the netTcpRelayBinding. Setting up network access to Azure But, if you get an error, it's because your network is secured and it's doing something to stop
the relay working.
The Service Bus relay bindings try to use direct TCP connections to Azure, so if ports 9350-9354 are available *outbound*, then
the relay will run through them. If not,
the binding steps down to standard HTTP, and issues a CONNECT across port 443 or 80 to set up a tunnel for
the relay. If your network security guys are doing their job,
the first option will be blocked by
the firewall, and
the second option will be blocked by
the proxy, so you'll get this error: System.ServiceModel.CommunicationException: Unable to reach sixeyed-ipasbr.servicebus.windows.net via TCP (9351, 9352) or HTTP (80, 443) - and that will probably be
the start of lots of discussions. Network guys don't really like giving servers special permissions for
the web proxy, and they really don't like opening ports, so they'll need to be convinced about this.
The resolution in our case was to put up a dedicated box in a DMZ, tinker with
the firewall and
the proxy until we got a relay connection working, then run some traffic which
the the network guys monitored to do a security assessment afterwards. Along
the way we hit a few more issues, diagnosed mainly with Fiddler and Wireshark: System.Net.ProtocolViolationException: Chunked encoding upload is not supported on
the HTTP/1.0 protocol - this means
the TCP ports are not available, so Azure tries to relay messaging traffic across HTTP.
The service can access
the endpoint, but
the proxy is downgrading traffic to HTTP 1.0, which does not support tunneling, so Azure can’t make its connection. We were using
the Squid proxy, version 2.6.
The Squid project is incrementally adding HTTP 1.1 support, but there's no definitive list of what's supported in what version (here are some hints). System.ServiceModel.Security.SecurityNegotiationException:
The X.509 certificate CN=servicebus.windows.net chain building failed.
The certificate that was used has a trust chain that cannot be verified. Replace
the certificate or change
the certificateValidationMode.
The evocation function was unable to check revocation because
the revocation server was offline. - by this point we'd given up on
the HTTP proxy and opened
the TCP ports. We got this error when
the relay binding does it's authentication hop to ACS.
The messaging traffic is TCP, but
the control traffic still goes over HTTP, and as part of
the ACS authentication
the process checks with a revocation server to see if Microsoft’s ACS cert is still valid, so
the proxy still needs some clearance.
The service account (the IIS app pool identity) needs access to: www.public-trust.com mscrl.microsoft.com We still got this error periodically with different accounts running
the app pool. We fixed that by ensuring
the machine-wide proxy settings are set up, so every account uses
the correct proxy: netsh winhttp set proxy proxy-server="http://proxy.x.y.z" - and you might need to run this to clear out your credential cache: certutil -urlcache * delete If your network guys end up grudgingly opening ports, they can restrict connections to
the IP address range for your chosen Azure datacentre, which might make them happier - see Windows Azure Datacenter IP Ranges. After all that you've hopefully got an on-premise service listening in
the cloud, which you can consume from pretty much any technology.
