Monetize your APIs with Azure API Management

In a world of Microservices and APIs, it might come a time when you realize you have some service that others might want to use.

Azure API Management was made for this purpose, to centralize the management of all your APIs.

It allows an easy tracking of usage, thanks to its subscription-key approach, with a unique key per user; so you can easily charge money to use your APIs.

But one caveat is that the user base in API Management is a "standalone" list, not necessarily aligned with Azure Active Directory (where you probably will have already all your users).

So if you want to align these two worlds, as of now you need to be creative, bend some concept, and implement a few tricks, as explained here.

Let's start from the basic, that is how Azure Active Directory works behind the scenes.

Here you can see the basic entities of Azure Active Directory for an Application: the App Registration and the Enterprise Applications; from these two entry points in the Azure portal you can manage almost everything about your App authentication.

Now, if you want to have some Customer specific division in your Azure Active Directory, you need to be a bit creative, and mis-use some entity to achieve your needs (I was hoping that AAD B2B or B2C would help achieving this, but apparently that is not the case so far).

As you can see in the above picture, you define CustomerA and CustomerB in AAD as Security Groups; then you can add to these group all the users from each Company, which you previously invited to your AAD as described here.

At this point you edit your Application Manifest in the AAD Registration and add two new AppRoles: CustomerA and CustomerB.

Then you open the Enterprise Applications menu of the AAD section in the Azure portal, and assign those new AppRoles to your users individually (behind the scenes through a AppRoleAssignment).

Now, since you use API Management, you need an App Registration in AAD also for its Developer portal (this is where your API consumers will login in order to learn about and test your APIs).

Once you did that, you can switch to the API Management Publisher portal, and import your API, as described here.

You will also need to create an Authorization Server in the Publisher Portal, so that it can use the OAuth2 Permissions in AAD, as shown in the picture above.


Now, to make things a bit more complex, you need to have your API users to register on the API Management Developer portal (as of now, "invite" for some reason does not work, so you have to rely on them to do it...).

Once they did register, and you have your users in API Management, you can create the Customer Groups as you did in AAD, choosing to "Add groups from AAD". in the Product section of the API Management Publisher portal. under the Visibility tab.

Obviously you need to have a Product for each Customer, with the same names as the Groups you previously created. That will allow for an easy match and assignment without confusion, as you can see in the picture here below.

Once you performed all these steps, you are now able to use Role-Based Authorization as usual at your Operation (action or method) level in your APIs, as shown here below.

Limit access to this Operation only to CustomerA users:

Limit access to this Operation only to CustomerB users:

Allow access to this Operation to both CustomerA and CustomerB users:

And thanks to the API Management Analytics section in the Publisher portal, you can see all details about usage of your APIs, by user, as well as Customer.

Now, the only work left for all this to be really useful and easy, is to automate it, of course!

Luckily API Management provides a REST API that you can use, more or less like the Azure Graph API.

But I will tell you about it in a next post.

;)

For now, Happy Holidays!