How to use an Azure API Management Service

In this new post, I want to show how to use an Azure API Management Service in a real world based on my recent experience. Sometimes it doesn’t work as you expect.

API Management (APIM) is a way to create consistent and modern API gateways for existing back-end services.

So, API Management helps organizations publish APIs to external, partner, and internal developers to unlock the potential of their data and services. Businesses everywhere are looking to extend their operations as a digital platform, creating new channels, finding new customers and driving deeper engagement with existing ones. API Management provides the core competencies to ensure a successful API program through developer engagement, business insights, analytics, security, and protection. You can use Azure API Management to take any backend and launch a full-fledged API program based on it.

Azure API Management Service Overview

To use API Management, administrators create APIs. Each API consists of one or more operations. For each API you can add to one or more products. To use an API, developers subscribe to a product that contains that API, and then they can call the API’s operation, subject to any usage policies that may be in effect. Common scenarios include:

• Securing mobile infrastructure by gating access with API keys, preventing DOS attacks by using throttling, or using advanced security policies like JWT token validation.
• Enabling ISV partner ecosystems by offering fast partner onboarding through the developer portal and building an API facade to decouple from internal implementations that are not ripe for partner consumption.
• Running an internal API program by offering a centralized location for the organization to communicate about the availability and latest changes to APIs, gating access based on organizational accounts, all based on a secured channel between the API gateway and the backend.

APIs and operations

APIs are the foundation of an API Management service instance. Each API represents a set of operations available to developers. Each API contains a reference to the back-end service that implements the API, and its operations map to the operations implemented by the back-end service. Operations in API Management are highly configurable, with control over URL mapping, query and path parameters, request and response content, and operation response caching. Rate limit, quotas, and IP restriction policies can also be implemented at the API or individual operation level.

For more information, see How to create APIs and How to add operations to an API.

Products

Products are how APIs are surfaced to developers. In API Management products have one or more APIs, and are configured with a title, description, and terms of use. Products can be Open or Protected. Protected products must be subscribed to before they can be used, while open products can be used without a subscription. When a product is ready for use by developers, it can be published. Once it is published, it can be viewed (and in the case of protected products subscribed to) by developers. Subscription approval is configured at the product level and can either require administrator approval, or be auto-approved.

Groups are used to manage the visibility of products to developers. Products grant visibility to groups, and developers can view and subscribe to the products that are visible to the groups in which they belong.

Groups

Groups are used to manage the visibility of products to developers. API Management has the following immutable system groups:

• Administrators – Azure subscription administrators are members of this group. Administrators manage API Management service instances, creating the APIs, operations, and products that are used by developers.
• Developers – Authenticated developer portal users fall into this group. Developers are :
  • the customers that build applications using your APIs.
  • granted access to the developer portal and build applications that call the operations of an API.
• Guests – Unauthenticated developer portal users, such as prospective customers visiting the developer portal of an API Management instance fall into this group. They can be granted certain read-only access, such as the ability to view APIs but not call them.

Service levels

Each API Management pricing tier offers a distinct set of features and per unit capacity. The following table summarizes the key features available in each of the tiers. Some features might work differently or have different capabilities depending on the tier. The feature-based tiers are:

• Consumption
• Developer
• Basic
• Standard
• Premium

Obviously, all the cool features are in the Standard and Premium edition. However, the Basic is cool with a bit of configuration. I’m going to explain what my scenario and problem was and then the solution. Consumption doesn’t guarantee SLA.

My scenario

So, to understand the problem I faced, I have to explain in “How to use an Azure API Management Service” what my requirements were and the limitation the Basic tier has.

First, all the resources and infrastructure are in Azure. Second, the APIs are coming from the researchers and they work with R and RStudio. That means what they are doing is a black hole for me (hahaha) but I know they are using a package for R to create APIs: this package is Plumber. In my point of view as architect I have to consider that there are some limitations in the implementation of the APIs with this technology, it is not .NET

Resources

So, as any other projects in R, the deployment will be with a Docker container. I have created another post where I explain how to deploy R application with Docker and Azure DevOps. For the purpose of this post, what it is important is I have to create a Virtual Machine in Azure to host Docker. Docker exposes the APIs and Swagger on a specific port (8000). I don’t want to expose this machine (or at least the APIs) to the internet also because they don’t have security.

Then, I need to protect the APIs and then I want in front of them the API Management Service (APIM). So, the API Management providers the security layer I need: it can verify the user based on a specific token or it is possible to configure an integration with Azure Active Directory and OpenID like Identity Server.

So, briefly, I’m going to create a new Virtual Machine with Docker that it exposes to the internet with a public IP. Then, I’m going to create an API Management Service that has its own public IP. Then, I have other resources such as Azure Functions or databases but this resources are not related to the API Management!

API Management Service has its own IP life long

Then, this is the important statement. So, in the Developer, Basic, Standard, and Premium tiers of API Management, the public IP addresses (VIP) are static for the lifetime of a service, with the following exceptions:

• The service is deleted and then re-created.
• The service subscription is suspended or warned (for example, for nonpayment) and then reinstated.
• Azure Virtual Network is added to or removed from the service.
• API Management service is switched between External and Internal VNet deployment mode.

Create a new API Management Service

First, because all the services are on Azure, you must have an account. If you want more information about Azure, I have created a post where I explain what Azure is and its functionalities. Second, you have to create a new Resource group (click on the link if you want to understand better the resource groups). Then, add a new resource. Search for API Management and then the wizard starts.

Click on Create and let the party start!

Basic settings

So, in this section, we have to select basic information settings for the API Management:

• Subscription
• Resource group
• Region
• Resource name
• Organization name
• Administrator email
• Price tier

I think those settings are self-explanatory. Therefore, I want to give you an advice about the naming convention. When you have a lot of resource groups and resources, you want to understand immediately what kind of resource you have an the purpose of each resource. For this reason, based on my experience, I wrote a document about the Azure naming convention you can adopt. Please, feel free to leave your question or comment in the post or in the forum.

Remember that each region has a different price for each service. Also, the pricing tier of this service changes a lot. The Developer tier gives you a lot of functionalities (like the Premium tier) but you can’t use it for production. For features and pricing, visit this Microsoft page.

So, because I don’t want to spend a fortune on this service, I’m going to use the Basic tier. It offers me almost everything I need, although I have to spend a bit more time in configuration and development. Click on Next : Monitoring.

Monitoring

So, with this option, you have all the requests and other logs in Application Insights. With Application Insights you can discover if there is any problem in your APIs and in the service, track all the requests, the status of the service and so on. Also, you can create graphs and tables for statistics.

To select an Application Insights to use for the API Management, you have to create this service before starting the procedure of creating a new API Management.

Then, next step Scale.

Scale

Here, you can select how many units you want to use. The choice is between 1 and 2 for the Basic tier. I choose 1.

Managed identity

So, a system assigned managed identity enables Azure resources to authenticate to cloud services (e.g., Azure Key Vault) without storing credentials in code. Once enabled, all necessary permissions can be granted via Azure role-based-access control. The lifecycle of this type of managed identity is tied to the lifecycle of this resource. Additionally, each resource (e.g., Virtual Machine) can only have one system assigned managed identity.

I choose Off.

Virtual network

Virtual network is not supported in the Basic, Standard, and Consumption tiers. That means we must to have a public IP for every service. Only in the Premium version, it is possible to not expose your servers or services to the internet and the communication between API Management and the APIs could be in the internal Azure network. This is a shame!

Protocol settings

Azure API Management supports multiple versions of TLS protocol for both client and backend sides as well as the 3DES cipher. The default settings for all protocol are Off.

Review + create

Then, the next step is Tags but I don’t use it. So, we can create the API Management! Finally, we have the service. We have to wait around 30 minutes Azure to complete the configuration. After that, we can start our configuration.

Configure Network security group (NSG)

You can use an Azure network security group to filter network traffic to and from Azure resources in an Azure virtual network. A network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources. For each rule, you can specify source and destination, port, and protocol.

You can deploy resources from several Azure services into an Azure virtual network. For a complete list, see Services that can be deployed into a virtual network. You can associate zero, or one, network security group to each virtual network subnet and network interface in a virtual machine. The same network security group can be associated to as many subnets and network interfaces as you choose.

Settings inbound connection between APIM and the virtual machine

So, the problem was to have secure APIs and don’t expose them to the internet. Also, I want that only the API Management has access to them. The Virtual machine exposes the APIs on port 8001.

Wrong selection

Then, in the Network security group, I want to add a new Inbound Security Rule. In the drawer, you can see there are some fields to fill. First, Source. I saw there is an option for Service Tag. If I select Service Tag, the following dropdown change the label in Source service tag. From this dropdown, you there is an option for ApiManagement.

This option doesn’t work as I thought! I spent a lot of time to understand that and a lot of people complain about it. When I spoke with the Microsoft support, they said a lot of people complains because this option doesn’t work as expected. Then, don’t use it.

Use IP Addresses

Finally, the solution. So, first take a look to the API Management service: in the Essentials section, you see the Virtual IP addresses for your service. This IP will be the same lifelong, as I said before. Copy this IP.

Now, go the to Network Resource Group to add a new Inbound Security Rule. Now, from Source select IP Addresses. Then, the following dropdown changes the label in Source IP addresses/CIDR ranges. Paste here the API Manager IP (only the IP). Then, select Destination and what port you want to use (in my case 8001), the protocol and the name.

This approach is working! Now, your API Management can reach the APIs in the Virtual Machine. Only the API Management is allowed to enter in this port. Your APIs are secure. Another important settings is about CORS. I’ll explain it in the next post.

Conclusion

In conclusion in this post, I explain how to use an Azure API Management Service with real APIs. Also, I shown how to protect the APIs changing the configuration in the Network security groups. I hope it will be useful. If you have any question, please use our forum.