{
  "$type": "site.standard.document",
  "canonicalUrl": "https://johnnyreilly.com/posts/azure-easy-auth-and-roles-with-dotnet-and-core",
  "description": "\"Easy Auth\" in Azure App Service doesnt currently work with .NET Core and .NET due to discrepancies. Open-source middleware can help solve the issue.",
  "path": "/posts/azure-easy-auth-and-roles-with-dotnet-and-core",
  "publishedAt": "2021-01-14T00:00:00.000Z",
  "site": "at://did:plc:yy3apqjlms24kso7ahn7lbmb/site.standard.publication/3mova7c4nho2b",
  "tags": [
    "azure",
    "auth",
    "easy auth"
  ],
  "textContent": "Azure App Service has a feature which is intended to allow Authentication and Authorization to be applied outside of your application code. It's called \"Easy Auth\". Unfortunately, in the context of App Services it doesn't work with .NET Core and .NET. Perhaps it would be better to say: of the various .NETs, it supports .NET Framework. To quote the docs:\n\n> At this time, ASP.NET Core does not currently support populating the current user with the Authentication/Authorization feature. However, some 3rd party, open source middleware components do exist to help fill this gap.\n\nThanks to Maxime Rouiller there's a way forward here. However, as I was taking this for a spin today, I discovered another issue.\n\n\n\nIf this post is interesting to you, you may also want to look at this one where we try to use Microsoft.Identity.Web for the same purpose.\n\nIf you're looking for information about Easy Auth and authentication with .NET and Azure Container Apps, you can find it here.\n\nWhere are our roles?\n\nConsider the following .NET controller:\n\nThe three endpoints above restrict access based upon roles. However, even with Maxime's marvellous shim in the mix, authorization doesn't work when deployed to an Azure App Service. Why? Well, it comes down to how roles are mapped to claims.\n\nLet's back up a bit. First of all we've added a dependency to our project:\n\nNext we've updated our Startup.ConfigureServices such that it looks like this:\n\nWith the above in place, either the Microsoft Identity platform will directly be used for authentication, or Maxime's package will be used as the default authentication scheme. The driver for this is Env which is an IHostEnvironment that was injected to the Startup.cs. Running locally, both authentication and authorization will work. However, deployed to an Azure App Service, only authentication will work.\n\nIt turns out that directly using the Microsoft Identity platform, we see roles claims coming through like so:\n\nBut in Azure we see roles claims showing up with a different type:\n\nThis is the crux of the problem; .NET and .NET Core are looking in a different place for roles.\n\nRole up, role up!\n\nThere wasn't an obvious way to make this work with Maxime's package. So we ended up lifting the source code of Maxime's package and tweaking it. Take a look:\n\nThere's a number of changes in the above code to Maxime's package. Three changes that are not significant and one that is. First the insignificant changes:\n\n1. It uses System.Text.Json in place of JSON.NET\n2. It uses C#s nullable reference types\n3. It changes the extension method signature such that instead of entering services.AddAuthentication().AddEasyAuthAuthentication((o) => { }) we now need only enter services.AddEasyAuthAuthentication()\n\nNow the significant change:\n\nWhere the middleware encounters claims in the X-MS-CLIENT-PRINCIPAL header with the Type of \"roles\" it creates brand new claims for each, with the same Value but with the official Type supplied by ClaimsTypes.Role of \"http://schemas.microsoft.com/ws/2008/06/identity/claims/role\". The upshot of this, is that when the processed claims are inspected in Azure they now look more like this:\n\nAs you can see, we now have both the originally supplied roles _as well_ as roles of the type that .NET and .NET Core expect. Consequently, roles based behaviour starts to work. Thanks to Maxime for his fine work on the initial solution. It would be tremendous if neither the code in this blog post nor Maxime's shim were required. Still, until that glorious day!\n\nUpdate: Potential ways forward\n\nWhen I was tweeting this post, Maxime was good enough to respond and suggest that this may be resolved within Azure itself in future:\n\n> Oh, so that's why they removed the name? 😲😜 Jokes aside, we hope that this package won't be necessary for the future. I know that @mattchenderson is part of a working group to update Easy Auth. Might want to make sure you follow him as well. 😁\n>\n> — Maxime Rouiller (@MaximRouiller) January 14, 2021\n\nThere's a prospective PR that would add an event to Maxime's API. If something along these lines was merged, then my workaround would no longer be necessary. Follow the PR here.",
  "title": "Azure App Service, Easy Auth and Roles with .NET"
}