Sentinet – Service Virtualization Part 7 - BizTalk Server

In the previous blog post I demonstrated how I can secure my internal BizTalk services application with requirements for Federated Security based on SAML tokens. The goal was to enable my BizTalk service to be a “claims-aware” application. Just like with all other cases of virtualizing BizTalk services through Sentinet, turning the BizTalk service application into a “claim-aware” application did not require any coding or configuration changes, the existing BizTalk application remained deployed and configured as is.

In this post I would like to continue where I left off in the previous post, and demonstrate how to set up yet another endpoint in the virtual service. This will be the endpoint that leverages the Microsoft Azure Service Bus so that my internal BizTalk services application can be accessible from outside of the internal network through the Azure Service Bus Relay Service.

The Microsoft Azure Service Bus Relay service enables you to build hybrid applications that run in both an Azure datacenter and your own on-premises enterprise environment. The Service Bus relay facilitates this by enabling you to securely expose services and APIs that reside within a corporate enterprise network to the public cloud, without having to open up a firewall connection or requiring intrusive changes to a corporate network infrastructure.

Sentinet allows any service, in this case a service hosted in BizTalk, to be on-boarded onto the Microsoft Azure Service Bus infrastructure without any reconfigurations, redeployments or potential security keys compromises. By configuring the Sentinet Node, which I will show in this post, you can dynamically open and manage Microsoft Azure Service Bus endpoints and authenticate virtual services with the Microsoft Azure ACS service. See the diagram below that shows my objective of this post.



The high level flow of interaction is as follows:

1. Client sends a request to the relay endpoint hosted by the Azure Service Bus relay service.
2. The request is forwarded (“relayed”) to the Sentinet Node that sits in front of the BizTalk hosted service. Both Sentinet Node and BizTalk server are behind the corporate firewall.
3. The request received by the virtual service hosted in the Sentinet Node will be authenticated, authorized and forwarded to the BizTalk service that internally routes the request to the WCF-SQL Send Port. Send Port is configured to select records from the SQL Server database.
4. The SQL Server database handles SQL statements and returns datasets to the WCF-SQL Send Port.
5. WCF-SQL Send Port forms response message from the received datasets.
6. Response message flows all the way back to the client.

The interesting part here is the interaction between external clients and the internal Sentinet Node through the Azure Service Bus. Virtual service hosted in the Sentinet Node will be configured to enable automatic registration of its endpoint with the Azure Service Bus. The Sentinet Node will walk up to the Service Bus namespace and it will reserve for its virtual service an external address relative to the Service Bus namespace address (with scenario in this post the relative address reserved for my virtual service endpoint is RunnerCloud (1 in the diagram below). The Service Bus namespace is created through the Microsoft Azure Portal. The namespace address and the relative address form a worldwide unique external address. In my case the namespace address is sltn2014.servicebus.windows.net while the relative address is RunnerCloud, so that the combined address sltn2014.servicebus.windows.net/RunnerCloud can be now turned into an actual http, https or native sb address that is accessible anywhere in the world, while the actual internal service endpoint is behind Microsoft Azure infrastructure and internal corporate firewall.

To send a message to that endpoint a client will create a connection to the front end node on the Service Bus, where it connects to a forwarder (2 in the diagram below). The forwarder will communicate with the routing fabric to learn who owns the address (3 in the diagram below). It will send a control message to the address that will flow to the receiver (i.e. receive location) and will then rendezvous with the forwarder (4 in the diagram below). Now the relayed connection is realized and regular web service traffic will flow through it. Client applications can use http, https or sb outbound connections and no firewall ports need to be open for the service inbound traffic.



The setup of the virtual service endpoint and the security configuration consists of the following steps, which I will be covering in more details later in this post:

• Setup a Sentinet Node Base Addresses for Microsoft Azure Service Bus
• Create the endpoint for the Sentinet virtual service.
• Write a test client to access the virtual service endpoint.

The first step is to add Microsoft Service Bus address to the Sentinet Node Base Addresses. Basically, all the Node’s base addresses inherit their base addresses from the IIS server configuration, since the Sentinet Nodes always run inside IIS server. As a result of this inheritance, all Sentinet virtual services have their addresses derived from the Sentinet Node base addresses.



This is not true however for the virtual services connected to the Service Bus Relay service since these virtual service addresses are derived from Microsoft Azure Service Bus itself. For the Azure Service Bus specifically, IIS Server is simply a process that hosts Sentinet Node applications. IIS server provides Sentinet Nodes with the reliability of its infrastructure such as application pools isolation, scheduled app pools recycling, etc., but IIS server does not provide Sentinet Node applications with its own listening capabilities because they are irrelevant to the Azure Service Bus architecture. That means that Microsoft Service Bus addresses are configured straight from the Sentinet Administration Console rather than from the Node Configuration Wizard embedded in the IIS Manager console. Below are the steps to add the Microsoft Service Bus base address to the Sentinet Node:

1. Select the Sentinet Node tree item in the Repository tree-view and click the Modify toolbar button.
2. Click the Add Addresses button for the Microsoft Service Bus base addresses.
3. In the Add Microsoft Service Bus Address wizard:

• Select address transport scheme that will be used by the consumers of the virtual services hosted by the Sentinet Node. Transport schemas available for Microsoft Service Bus external addresses are http, https or sb. Provide [namespace] that matches the Microsoft Azure Service Bus namespace associated with your Microsoft Azure account.

The Address is formed from the selected protocol, the Azure account namespace and the default DNS, servicebus.windows.net. In my case the new Microsoft Service Bus base address added to the Sentinet Node will be sb://sltn2014.servicebus.windows.net

• Select Service Bus Credentials Type (Shared Secret is the common credential type that is supported since early versions of the Microsoft Azure Service Bus).
• Click Next.
• The Shared Secret credentials are obtained from the Microsoft Azure Portal. Through the Portal you can navigate to the Service Bus and select the appropriate namespace and click connection information in the bottom pane.

• Default Issuer and Default Key credentials captured from the above screen, use in the next step of the Sentinet wizard to configure new Sentinet Node base address with the Azure Service Bus credentials.

• Click Finish. The base address will now be added, and it shows up in the Node Base Addresses list.

Note that more Service Bus base addresses can be added to the same Sentinet Node. These addresses can be associated with different transport schemes, different Service Bus namespaces and different Service Bus credentials. Existing Service Bus address and its credentials can be changed at any time by clicking the Modify button located next to each Service Bus address entry. What is important to emphasize here, is that this step effectively provides central and remote configuration of the Sentinet Node with your Azure Service Bus account(s) and its namespace(s). This is a one-time user action. Once Sentinet Node is configured with your Azure Service Bus namespace, the Node gets the capability to dynamically open (or close) any number of Service Bus endpoints in your Azure Service Bus namespace. Ultimately it means that the Node gets the capability to dynamically connect any number of its virtual services to the Azure Service Bus relay service making them accessible from outside of the corporate networks.

In the previous step we have set up Sentinet Node with connection to the Azure Service Bus namespace (in the Sentinet terms, we have added Microsoft Service Bus address and its configuration to the list of the Node base addresses). Our next step in this sample is to set up an endpoint for our virtual service that is configured with the Service Bus (i.e. relay). In other words, we have just configured Sentinet Node with the generic capability to connect its virtual services to Azure Service Bus, and now we want to use this new capability, and we want to add a new endpoint to our existing virtual service. New service endpoint will be called ServiceBus. It will be used to expose externally (through Microsoft Azure cloud) our existing internal virtual service. In the Sentinet Console we use the same drag-and-drop steps as if we used to create any other virtual service endpoint (those steps are repeatedly described in my previous parts of this blog article series). This time, however, we also have the sb://sltn2014.servicebus.windows.net in the drop-down list of available virtual service base addresses. We will choose this address and type RunnerCloud in relative part of the endpoint address, so that the consumer facing full address now becomes sb://sltn2014.servicebus.windows.net/RunnerCloud. Note, we could have used the same process to expose our service via http or https protocol.



Next we will configure, the endpoint with a policy compatible with sb protocol. We will use the following binding:

<bindings>
    <netTcpRelayBinding>
        <binding name="defaultBinding">
            <security relayClientAuthenticationType="None" />
        </binding>
    </netTcpRelayBinding>
</bindings>


In this scenario we choose the netTcpRelay binding with no further authentication. However, we still need to assign an access rule to the endpoint. For simplicity in this sample the access to the service will be for anyone. The Everyone Access Rule is available with the default product installation. The Access Control is driven by the Access Rules located under the Access Rules folder in the Repository tree. You can expand the Access Rule folder in the Repository view. Drag-and-drop the Everyone Access Rule on the root of the Virtual Service tree and it will be assigned to your service with the Permit permission.

Our final step in this sample is too test the endpoint. We will write a simple test client (console app) to access the service endpoint. In Visual Studio we create a new console application, set a service reference to the virtual service with the newly created endpoint. Note the immediate benefit for developers of using Sentinet Repository here. When we build the client application in Visual Studio we select Add Service Reference and provide virtual service’s WSDL URL from the Sentinet Repository. Sentinet virtual service was configured with the binding that has everything in it. All we need to do is to write the actual code to call the service, while all configurations for our test client will be automatically generated off the Sentinet Repository.

The code in our client looks like below:



Below is the generated binding in the app.config:



When we run the client it calls the virtual endpoint and we can view how the call to the virtual endpoint is made through the monitoring feature of the Sentinet. You can examine this call from the Monitoring screen with all the tracking details, where you can view messages coming in and out of the virtual service. Below is the screenshot of the recorded message in clear text after it is received, decrypted and decoded by the virtual service.



The response message before encryption and encoding is also visualized below.





Note that Sentinet provides here monitoring, tracking and optional recording of the messages that arrive from the Azure Service Bus relay service. This communication leg between cloud-based relay service and on-premises Sentinet virtual services represents that “firewall tunneling” effect that is so special to the Azure Service Bus technology. All messages coming through this channel are always encoded using Microsoft-specific, non-interoperable binary serialization. Nevertheless, Sentinet decodes these messages and shows them on the screens above in a human-readable XML representation.


In this post I have discussed and demonstrated how to create a Sentinet virtual endpoint that is exposed through the Microsoft Azure Service Bus. Effectively, the objective of this use case was to enable my BizTalk service to be a “cloud-aware” application supporting hybrid connectivity (i.e. between the cloud and on premise) with no coding or any changes in how my existing BizTalk application is deployed and configured. BizTalk application was also extended to service calls monitoring and could have been easily extended with additional authentication and authorization (which I avoided for the sake of simplicity of this article). At the same time, as a developer of a client application, I leveraged Sentinet Repository and Visual Studio to quickly build my test client application with the minimum effort.



In the next post I will discuss and demonstrate another interesting use case exploring the combination of Sentinet and Microsoft Azure BizTalk Service (MABS).

Cheers,

Steef-Jan