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

• Integration Patterns with Azure Service Bus Relay, Part 1: Exposing the on-premise service
• Integration Patterns with Azure Service Bus Relay, Part 2: Anonymous full-trust .NET consumer

As the patterns get further from the simple .NET full-trust consumer, all that changes is the communication protocol and the authentication mechanism. In Part 3 the scenario is that we still have a secure .NET environment consuming our service, so we can store shared keys securely, but the runtime environment is locked down so we can't use Microsoft.ServiceBus to get the nice WCF relay bindings. To support this we will expose a RESTful endpoint through the Azure Service Bus, and require the consumer to send a security token with each HTTP service request.

Pattern applicability

This is a good fit for scenarios where:

• the runtime environment is secure enough to keep shared secrets
• the consumer can execute custom code, including building HTTP requests with custom headers
• the consumer cannot use the Azure SDK assemblies
• the service may need to know who is consuming it
• the service does not need to know who the end-user is

Note there isn't actually a .NET requirement here. By exposing the service in a REST endpoint, anything that can talk HTTP can be a consumer. We'll authenticate through ACS which also gives us REST endpoints, so the service is still accessed securely. Our real-world example would be a hosted cloud app, where we we have enough room in the app's customisation to keep the shared secret somewhere safe and to hook in some HTTP calls. We will be flowing an identity through to the on-premise service now, but it will be the service identity given to the consuming app - the end user's identity isn't flown through yet.

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

Authenticating and authorizing with ACS

We'll follow the previous examples and add a new service identity for the namespace in ACS, so we can separate permissions for different consumers (see walkthrough in Part 1). I've named the identity partialTrustConsumer. We’ll be authenticating against ACS with an explicit HTTP call, so we need a password credential rather than a symmetric key – for a nice secure option, generate a symmetric key, copy to the clipboard, then change type to password and paste in the key:

We then need to do the same as in Part 2 , add a rule to map the incoming identity claim to an outgoing authorization claim that allows the identity to send messages to Service Bus:

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

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

RESTfully exposing the on-premise service through Azure Service Bus Relay

The part 3 sample code is ready to go, just put your Azure details into Solution Items\AzureConnectionDetails.xml and “Run Custom Tool” on the .tt files.  But to do it yourself is very simple. We already have a WebGet attribute in the service for locally making REST calls, so we are just going to add a new endpoint which uses the WebHttpRelayBinding to relay that service through Azure. It's as easy as adding this endpoint to Web.config for the service:

        <endpoint address="https://sixeyed-ipasbr.servicebus.windows.net/rest"
                  binding="webHttpRelayBinding" 
                  contract="Sixeyed.Ipasbr.Services.IFormatService"
                  behaviorConfiguration="SharedSecret">
        </endpoint>

- and adding the webHttp attribute in your endpoint behavior:

          <behavior name="SharedSecret">
            <webHttp/>
            <transportClientEndpointBehavior credentialType="SharedSecret">
              <clientCredentials>
                <sharedSecret issuerName="serviceProvider"
                              issuerSecret="gl0xaVmlebKKJUAnpripKhr8YnLf9Neaf6LR53N8uGs="/>
              </clientCredentials>
            </transportClientEndpointBehavior>
          </behavior>

Where's my WSDL?

The metadata story for REST is a bit less automated. In our local webHttp endpoint we've enabled WCF's built-in help, so if you navigate to:

http://localhost/Sixeyed.Ipasbr.Services/FormatService.svc/rest/help

- you'll see the uri format for making a GET request to the service. The format is the same over Azure, so this is where you'll be connecting:

https://[your-namespace].servicebus.windows.net/rest/reverse?string=abc123

Build the service with the new endpoint, open that in a browser and you'll get an XML version of an HTTP status code - a 401 with an error message stating that you haven’t provided an authorization header:

<?xml version="1.0"?><Error><Code>401</Code><Detail>MissingToken: The request contains no authorization header..TrackingId:4cb53408-646b-4163-87b9-bc2b20cdfb75_5,TimeStamp:10/3/2012 8:34:07 PM</Detail></Error>

By default, the setup of your Service Bus endpoint as a relying party in ACS expects a Simple Web Token to be presented with each service request, and in the browser we're not passing one, so we can't access the service. Note that this request doesn't get anywhere near your on-premise service, Service Bus only relays requests once they've got the necessary approval from ACS.

Why didn't the consumer need to get ACS authorization in Part 2?

It did, but it was all done behind the scenes in the NetTcpRelayBinding. By specifying our Shared Secret credentials in the consumer, the service call is preceded by a check on ACS to see that the identity provided is a) valid, and b) allowed access to our Service Bus endpoint. By making manual HTTP requests, we need to take care of that ACS check ourselves now.

We do that with a simple WebClient call to the ACS endpoint of our service; passing the shared secret credentials, we will get back an SWT:

var values = new System.Collections.Specialized.NameValueCollection();
values.Add("wrap_name", "partialTrustConsumer"); //service identity name
values.Add("wrap_password", "suCei7AzdXY9toVH+S47C4TVyXO/UUFzu0zZiSCp64Y="); //service identity password
values.Add("wrap_scope", "http://sixeyed-ipasbr.servicebus.windows.net/"); //this is the realm of the RP in ACS

var acsClient = new WebClient();
var responseBytes = acsClient.UploadValues("https://sixeyed-ipasbr-sb.accesscontrol.windows.net/WRAPv0.9/", "POST", values);
rawToken = System.Text.Encoding.UTF8.GetString(responseBytes);

With a little manipulation, we then attach the SWT to subsequent REST calls in the authorization header; the token contains the Send claim returned from ACS, so we will be authorized to send messages into Service Bus.

Running the sample

Navigate to http://localhost:2028/Sixeyed.Ipasbr.WebHttpClient/Default.cshtml, 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").