Micro-services based architectures: Exposing and Securing Azure Service Fabric Web APIs – Part 1

Azure Service Fabric

Why Azure Service Fabric

Service Fabric is a distributed systems platform that you can use to build scalable, reliable, and easily-managed applications for the cloud. Service Fabric is a great fit for customer facing, but equally, it is a great fit for internal facing services used by internal applications, as its helps to build micro-services based architectures that will deliver great agility benefits.
This blog post will describe a real scenario in which we’ve been working on with a great partner using Service Fabric on Azure. This document covers:
1 – How to expose Web APIs to external consumers, with external I mean consumers that are not on the Service Fabric cluster Network (VNET).
2 -How a Service Fabric cluster looks like on Azure (during public preview)
3 -How we should apply a consistent approach to build secure applications and environments.

The Scenario

The organization I’ve been working with want to develop a new back-end system and break down the existing APIs / capabilities into Microservices, so they could more easily, manage, version and deploy them. For that purpose we will adopt a Micro-services approach using Service Fabric on Azure.
The consumers of the Web APis will be (at least initially) several corporate applications that reside on-premise, so we will have to implement an integration strategy that will allow the corporate systems to securely consume Web APIs hosted on Azure Service Fabric.

Get the Code !

Use this ARM template and PS Script to create a customized Azure Service Fabric in a fully automatic manner.

Exposing WebAPIs on Azure Service Fabric

For this scenario, we are using both Reliable Actors and Reliable Services. I like the fact that with Service Fabric we can use both programing models, so we can choose the best model for each scenario. You can read more about both programing models Choose a framework for your service.
On top of the Services / Actors, if you want to expose Web APIs, you can use a Stateless Service and OWIN listener; in this way, you can expose your APIs to consumers that reside outside the Service Fabric cluster. More info Getting Started with Microsoft Azure Service Fabric Web API services with OWIN self-host.
You would typically deploy your Stateless Services on all the nodes (you can use -1 instance count), so you host the Web API on all the Service Fabric nodes. We call this pattern a Stateless Gateway.

The following diagram shows:
– A 5 Nodes Service Fabric cluster
– 3 Actor Types ( Blue, Orange and Green) and Multiple Actor Instances for each actor type
– 2 Stateless Services that expose Web APIs so the Actors can be called from outside the cluster by using RES APIs. Note, that you don’t have to expose all the Reliable Actors or Services, you can choose which ones you want to expose.

The key design considerations that we have to take on this scenario are:
Do we need multiple Stateless gateways or can we centralize all the gateway functionality into the same Gateway?
For this scenario, we decided to use one Stateless Gateway per API, as it is more self-contained and we can have more control and implement specific functionality per Service. On the negative side, I think that we will add many Stateless Gateways and they will all do similar things. All in all, for this scenario we decided to go with one Gateway per Web API, however I still don’t have enough evidence to support a definitive answer for this question.
How do you expose the API Endpoints?
Do we want to use the same port or different ports? You can actually use the same port, even if you host multiple OWIN listeners on the same VM; the only requirement is that you use different subpaths to host your different Web APIs. For instance, let’s say that you have 2 services ( hello, goodbye). You could :

1. Expose each service on different ports :80/api/hello , :81/api/goodbye. I think this approach adds unnecessary complexity, as it will be more difficult to discover the Services.

2. Expose all the services on the same port and use subpaths :
• :80/api/hello
• :80/api/goodbye
I like this approach more as I think it publishes a more elegant API, and this is the approach that we are using on our scenario; but the point is that you can use both techniques.
The following class shows how to register an Owin Listener using sub-paths.

public class StatelessActorGateway : StatelessService
        protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
            return new[]
                new ServiceInstanceListener(initParams => new OwinCommunicationListener(initParams, "api/hello")),


        protected override async Task RunAsync(CancellationToken cancellationToken)
            // TODO: Replace the following with your own logic.

            int iterations = 0;
            while (!cancellationToken.IsCancellationRequested)
                ServiceEventSource.Current.ServiceMessage(this, "Working-{0}", iterations++);
                await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);

Service Fabric clusters on Azure.

After defining your strategy for exposing the APIs, we now are going to discuss how you can host those APIs on Azure and apply a secure approach to minimize unnecessary risks.
You can create a Service Fabric cluster on Azure, either using the Management Portal or using an ARM Template :
Setup a Service Fabric cluster in the Azure portal
Setup a Service Fabric cluster using an ARM template

Whatever option you choose, during public preview, the following Azure Resources will be created :

– A VNET ( with two subnets ( and
– 5 VMs cluster (this is the minimum supported cluster size), each VM with one private NIC
– All the Service Fabric Nodes will be deployed subnet1 and on the same Availability Set.
– A load balancer with :
1. One NAT rule for each Node, so you can RDP into all the Service Fabric nodes
2. Two balancing rules (LBRule and LBHttpRule) for the Service Fabric Management API
3. Two balancing rules for Application endpoints (AppPortLBRule1 and AppPortLBRule2), these are provided mainly for example purposes, so will have to modify them and redirect the rules to the endpoints that your Stateless gateway expose.

Additionally, you can choose between whether you want to secure the management endpoints. For any non dev related cluster, encryption and SSL is a must. The scripts / ARM templates available on the Git Hub Repo fully automate the process of creating Service Fabric clusters that leverage certificates to encrypt traffic and authenticate administrators
See Securing a Service Fabric cluster and Create a Secure Service Fabric cluster on Azure in a fully automated manner

Getting Ready to Support Real Production Workloads

The proposed approach by the Templates is perfectly fine for Dev and Test Purposes, but for production ready workloads; customers will typically want to customize and add security policies. For instance, customers would typically want to:
1. Expose all the Web APIs over HTTPS by using an Application Gateway
2. Apply IP Filters, so only services from the corporate network can call the Web APIs, we will do this by applying Network Security Groups.
3.Secure the Service Fabric Nodes, so they don’t expose RDP endpoints. Only a Jumpbox VM will be accessible by RDP.
4.Add Web Application Firewalls to apply more advanced and granular threat / intrusion detection.

These requirements can be applied by leveraging Azure Infrastructure related capabilities (Application Gateway, Network Security Groups, Web Application Firewalls and Security Centre). In addition to these requirements, you will very likely want to:
1.Add authentication / authorization capabilities to your Web APIS.
2.Manage Data in a secure way, potentially you might need to encrypt the data (actors and collections).

The following diagram shows the architecture and the objects that the new template will create :

What is next

During the next sections we will propose a holistic approach to tackle security requirements.