NotAllAboutCode

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 order to run your API behind Azure  API Management there are a few important steps to take. You first open the API Management Publisher Portal , this can be done from the Azure Portal by selecting API Management services and your service instance. If you did not create yet your instance, refer to this article . Import API If you want to import your  API  (rather than creating everything manually), it is essential that you have a correct  Swagger   definition. I wrote a post about it, so if not sure, have a look  here . You can import definitions in the  Swagger ,  WADL  and  WSDL  format. Assign a Product Once you imported the  API  in  API Management , you need to assign it to a Product , so users can subscribe to it and obtain their personal Subscription Key , required to access your API . You can either use the existing Starter or Unlimited , or create a new one. Setup Authorization Server Now you can create the Authorization Server that you will us

Some time ago I wrote about a bug that took a month to be solved, involving a 401 - Unauthorized Access to an Azure AppService . After lots of troubleshooting, that issue got a solution from Microsoft support with a little code snippet that handles the AAD redirection at run-time, rather than relying on the config file value. Turns out that this code snippet caused another issue, namely a Owin/Katana bug. This time the same AppService (that runs just fine on Azure ), cannot run anymore locally under IIS , as it generates an infinite redirect loop between the Azure login page and the AppService . After another month of troubleshooting with Microsoft support , bouncing from one team to another ( AppService , IIS , AAD , you name it), they finally were able to reproduce the core issue, which eventually got acknowledged as an official bug (I will update this post with the link to it as soon as I will receive it from Microsoft support ): Symptom: The MVC project stopped wo