NotAllAboutCode

Here's a diagram to show what are the main components involved in an Azure AppService deployment and configuration, between the actual application and the Azure Active Directory setup. For those not familiar with Azure, it can get confusing between the concepts of Directory , Tenant , Subscription , and all the sub-components that need to be properly configured when deploying to Azure . Hopefully this high-level diagram can clarify a bit more. A few notes: you can create several Tenants under a single Directory . you can use Azure Active Directory in any Tenant (not necessarily the one where the application is deployed). you can use the basic Azure Active Directory authentication and authorization features for free (without a Subscription attached to it), but as soon as you need advanced features (let's say MFA ), then you need to buy one of the AAD Premium plans. You do need a Subscription for deployment of apps in this setup, a SSL Certificate is

So here's another rant about Microsoft inconsistency and UN-usability of their products (sorry but I cannot hold this anymore).. Since it's been introduced years ago, Microsoft Powershell looked very promising, with its CMDLet approach to reuse scripts, not only for sysadmin tasks, but for almost everything Microsoft . There is only one problem with it (still nowadays): inconsistency . The reason why I say this, is because most of the times (I am serious, most of them) I try to use Powershell , I get the famous error message: The term '[ Put your Powershell Module name here]' is not recognized as the name of a cmdlet, function, script file, or operable program. That seems like a trivial error, so the next thing to do is to install the missing module. This generally requires a few steps: Figure out which module contains the command you are trying to run (not always straightforward). Figure out which version of the module contains the exact comman

I mentioned before about the Azure and Microsoft Graph APIs , and the fact that Microsoft recommends to use the latter one. In fact, every page of documentation related to the Azure Graph API contains this disclaimer: We strongly recommend that you use  Microsoft Graph   instead of Azure AD Graph API to access Azure Active Directory resources. Our development efforts are now concentrated on Microsoft Graph and no further enhancements are planned for Azure AD Graph API. There are a very limited number of scenarios for which Azure AD Graph API might still be appropriate; for more information, see the  Microsoft Graph or the Azure AD Graph I can see this disclaimer in articles dated back as much as June 2017. Still, as of now ( February 2018 ), the Microsoft Graph API only supports a tiny bunch of operations in its official version 1.0 , and a few more in its beta version , while most of the operations that are supported on the Azure Graph API (soo ma

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