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

So you created your shiny .NET REST API , and added the NuGet package Swashbuckle.Core which generated the SwaggerConfig.cs file in the App_Start of your API project. All good, now you can browse your API definition and even test your API operations! So you think you have a OpenAPI Specification file now... well, hold your horses! Turns out that the  .NET  implementation with the  SwaggerConfig.cs  is not so strict on enforcing the Specification, and will produce a JSON that contains errors when checked for compliancy. To make sure that your  Swagger definition  is indeed  OpenAPI Specification  compliant, you can download your generated Swagger JSON and upload it to either  SwaggerHub  or  Swagger Editor . If any error shows up there after parsing your  JSON  into  YAML , you first have some work to do to fix those. You might see errors such as "Semantic error at paths ... Equivalent paths are not allowed.", "Schema error at paths ... should NOT h

I bumped into a nice article, which tells stuff very well known to me and my colleagues nowadays. However it is always good to share it, as it is too easy to get caught in the code details and forget the "big picture". Consider it like a basic programmer wisdom checklist: https://blog.toggl.com/how-to-be-better-programmer/

And here is the official video of the recent Openhack Amsterdam that I went to, earlier this month. Enjoy! (yes I am the one on the right end of the screen in the picture) :)

Some time ago I wrote about User App Provisioning in Azure , which can be achieved manually through the Azure Portal . But if you happen to have already an application that you use to manage your users and permissions, and you want to deploy such application to  Azure , you might want to automate things a bit more. At a high level, this is the Graph API flow: Find the User in AAD Invite the User to AAD Find the App to Assign in AAD Find existing App Assignment for the User Assign the App to the User This is the flow diagram (a bit more detailed): The Management App  (green color) is the main application where you already manage users and permissions, which did not require AAD integration so far. However, once the application is deployed to Azure , AAD integration becomes essential. This is the place where you would want to integrate this POC application. The POC application is represented by the App Provision App (yellow color), and it manages the  Graph API  f

As part of a security compliancy, we had our application (deployed in Azure ), scanned with a Pentest by an external company. I just received the Scan Reports , and I was surprised to see issues that I was sure we fixed (such as OWASP  XSS (Cross Site Scripting)  just to name one.. Well, after a quick analysis of the reports, it turns out that most of those issues belong to Azure resources! By having our API s behind Azure API Management , its  Developer Portal was scanned as well, and resulted in a few issues (between Low and Medium , nothing critical). The AAD login page , has a few of those issues as well, and because of the automatic redirect they seem caused by our app during the scan.. Obviously those resources are out of our control, and we can't do anything to fix those issues, maybe Microsoft will. At the same time it is nice to find out that the hard work to secure our app paid off, and only a few minor issues were found that actually belong to it. Th

Last Day. Challenge completed. New Stuff learned. Thanks Microsoft. Openhack Amsterdam

Keep hacking... Openhack Amsterdam

Having fun with Containers and Minecraft at Openhack Amsterdam :)

Introduction This post is quite technical (and long, and detailed), so sit down, enjoy your coffee, and let’s get started! Containers are becoming the way forward in the DevOps and IT worlds, as they greatly simplify deployments of applications and IT infrastructure . RabbitMQ is “the most widely deployed open source message broker”, and easy to use within a Docker Container Image . Kubernetes is considered the De-facto Standard for Container Orchestration . To follow this tutorial you can use the built in Azure Cloud Shell , or download and install the Azure CLI , and use PowerShell locally. Make sure you have installed  Azure PowerShell . You will also need Kubectl , so make sure you install that too (I suggest Choco as the easiest way). Here I am using PowerShell . Resource Group First you have to login to Azure through PowerShell: az login You will receive a message such as: To sign in , use a web browser to open the page http

Just a quick one today: Deployment Slots are one way to manage your Azure App Service deployments, giving you the option to do a " hot swap " of a live production application with little to no downtime. At the same time they allow you to easily manage your app versioning, by making sure that you always have a " Last Known Good " version of your app, a few clicks away from being rolled back on production when something goes wrong in your release. You can set up VSTS to configure your Staging Slot before deploying to it, as mentioned in a previous post of mine . Here is a quick overview of the common Deployment Slots usage:

When using Azure Active Directory (AAD) as Identity Provider for your Azure App Services , you will set up App Registrations to tell AAD how to handle your app authentication. One important bit of this is the ReplyURL ( RedirectUri ) that you need to specify for AAD to redirect the user back to your app after valid authentication. The usual flow is: User requests your app URL (ie: https://myappservice.azurewebsites.net ) User is redirected to the AAD Login page ( https://login.microsoftonline.com /.../ oauth2/ authorize ) User inserts valid credentials User is redirected back to your defined RedirectUri as a logged on User ( https://myappservice.azurewebsites.net ) For this to happen, you will need to specify in your application as AppSettings in the web.config file:   < add key ="ida:PostLogoutRedirectUri“ value =" https://myappservice.azurewebsites.net " /> < add key = "ida:RedirectUri“ value =" https://