This is the second in the IPASBR series, see also:

• Integration Patterns with Azure Service Bus Relay, Part 1: Exposing the on-premise service

Part 2 is nice and easy. From Part 1 we exposed our service over the Azure Service Bus Relay using the netTcpRelayBinding and verified we could set up our network to listen for relayed messages. Assuming we want to consume that service in .NET from an environment which is fairly unrestricted for us, but quite restricted for attackers, we can use netTcpRelay and shared secret authentication.

Pattern applicability

This is a good fit for scenarios where:

• the consumer can run .NET in full trust
• the environment does not restrict use of external DLLs
• the runtime environment is secure enough to keep shared secrets
• the service does not need to know who is consuming it
• the service does not need to know who the end-user is

So for example, the consumer is an ASP.NET website sitting in a cloud VM or Azure worker role, where we can keep the shared secret in web.config and we don't need to flow any identity through to the on-premise service. The service doesn't care who the consumer or end-user is - say it's a reference data service that provides a list of vehicle manufacturers. Provided you can authenticate with ACS and have access to Service Bus endpoint, you can use the service and it doesn't care who you are.

In this post, we’ll consume the service from Part 1 in ASP.NET using netTcpRelay. The code for Part 2 (+ Part 1) is on GitHub here: IPASBR Part 2

Authenticating and authorizing with ACS

In this scenario the consumer is a server in a controlled environment, so we can use a shared secret to authenticate with ACS, assuming that there is governance around the environment and the codebase which will prevent the identity being compromised. From the provider's side, we will create a dedicated service identity for this consumer, so we can lock down their permissions. The provider controls the identity, so the consumer's rights can be revoked.

We'll add a new service identity for the namespace in ACS , just as we did for the serviceProvider identity in Part 1. I've named the identity fullTrustConsumer. We then need to add a rule to map the incoming identity claim to an outgoing authorization claim that allows the identity to send messages to Service Bus (see Part 1 for a walkthrough creating Service Idenitities):

Issuer: Access Control Service
Input claim type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
Input claim value: fullTrustConsumer
Output claim type: net.windows.servicebus.action
Output claim value: Send

This sets up a service identity which can send messages into Service Bus, but cannot register itself as a listener, or manage the namespace.

Adding a Service Reference

The Part 2 sample client code is ready to go, but if you want to replicate the steps, you’re going to add a WSDL reference, add a reference to Microsoft.ServiceBus and sort out the ServiceModel config. In Part 1 we exposed metadata for our service, so we can browse to the WSDL locally at: http://localhost/Sixeyed.Ipasbr.Services/FormatService.svc?wsdl

If you add a Service Reference to that in a new project you'll get a confused config section with a customBinding, and a set of unrecognized policy assertions in the namespace http://schemas.microsoft.com/netservices/2009/05/servicebus/connect. If you NuGet the ASB package (“windowsazure.servicebus”) first and add the service reference - you'll get the same messy config.

Either way, the WSDL should have downloaded and you should have the proxy code generated. You can delete the customBinding entries and copy your config from the service's web.config (this is already done in the sample project in Sixeyed.Ipasbr.NetTcpClient), specifying details for the client:

    <client>

      <endpoint address="sb://sixeyed-ipasbr.servicebus.windows.net/net"

                behaviorConfiguration="SharedSecret"

                binding="netTcpRelayBinding"

                contract="FormatService.IFormatService" />

    </client>

    <behaviors>

      <endpointBehaviors>

        <behavior name="SharedSecret">

          <transportClientEndpointBehavior credentialType="SharedSecret">

            <clientCredentials>

              <sharedSecret issuerName="fullTrustConsumer"

                            issuerSecret="E3feJSMuyGGXksJi2g2bRY5/Bpd2ll5Eb+1FgQrXIqo="/>

            </clientCredentials>

          </transportClientEndpointBehavior>

        </behavior>

      </endpointBehaviors>

    </behaviors>

The proxy is straight WCF territory, and the same client can run against Azure Service Bus through any relay binding, or directly to the local network service using any WCF binding - the contract is exactly the same. The code is simple, standard WCF stuff:

using (var client = new FormatService.FormatServiceClient())

{

outputString = client.ReverseString(inputString);

}

Running the sample

First, update Solution Items\AzureConnectionDetails.xml with your service bus namespace, and your service identity credentials for the netTcpClient and the provider:

  <!-- ACS credentials for the full trust consumer (Part2): -->

  <netTcpClient identityName="fullTrustConsumer"

                symmetricKey="E3feJSMuyGGXksJi2g2bRY5/Bpd2ll5Eb+1FgQrXIqo="/>

Then rebuild the solution and verify the unit tests work. If they’re green, your service is listening through Azure. Check out the client by navigating to http://localhost:53835/Sixeyed.Ipasbr.NetTcpClient. Enter a string and hit Go! - your string will be reversed by your on-premise service, routed through Azure:

Using shared secret client credentials in this way means ACS is the identity provider for your service, and the claim which allows Send access to Service Bus is consumed by Service Bus. None of the authentication details make it through to your service, so your service is not aware who the consumer is (MSDN calls this "anonymous authentication").