Cannot lock down API when emulating auth locally - Blazor stack

[egeyer]

Are you accessing the CLI from the default port :4280 ?

• [ ] No, I am using a different port number (--port) and accessing the CLI from that port
• [X] Yes, I am accessing the CLI from port :4280

Describe the bug

I cannot get API authentication working when running locally. It's possible I'm missing something in my setup, but I've read and searched documentation and haven't hit upon a solution. I'm running blazor wasm client side with a C# function api. Running the emulator and I can login and see the proper roles listed when I go to .auth/me. Client side authentication using Microsoft.Azure.Function.Authentication.WebAssembly package works fine. Pages properly authenticate using the Authorize attribute and views seem to properly respond to the authenticated state. The problem comes when trying to lock down the API.

My first attempt was to put the AllowedRoles in a route.

{
   "route": "/api/*",
   "methods": ["GET"],
   "allowedRoles": ["registereduser"]
},
{
   "route": "/api/*",
   "methods": ["PUT", "POST", "PATCH", "DELETE"],
   "allowedRoles": ["admin"]
}

This doesn't seem to do anything in the emulator. I can still see the calls being successfully made from the client side even when I'm not logged in.

I then moved on in my exploration and went to inspect what headers I'm getting in my api function. And I do not see any auth information. I made a test function to simply spit out all the headers and the x-ms-client-principal header is not present even when I make the call from an authenticated state.

Note that this all works perfectly fine when I'm actually running on Azure in a real static web app.

What am I missing? I really love the concept of being able to develop all of this locally, but trying to set this up has been kind of frustrating.

To Reproduce Steps to reproduce the behavior:

1. I created a blazor (.net 6) swa from the github template found at staticwebdev/blazor-starter
2. I modified it for authentication as seen in this tutorial: https://docs.microsoft.com/en-us/shows/azure-tips-and-tricks-static-web-apps/how-to-secure-your-c-api-with-azure-static-web-apps-13-of-16--azure-tips-and-tricks-static-web-apps
3. I run the swa cli using the following command: swa start http://localhost:5000 --run "dotnet run --project Client/Client.csproj" --api-location Api
4. using a login button that simulates aad login, I can see the emulator's auth page and I enter a test username and the roles
5. I can see those roles represented in the .auth/me page
6. No auth information is attached when I call the api. The api is being called using the following syntax (Standard from the template): await Http.GetFromJsonAsync<WeatherForecast[]>("/api/WeatherForecast") ?? new WeatherForecast[]{};

Expected behavior I would expect to be able to get/create the ClaimsPrincipal using the information found here: (https://docs.microsoft.com/en-us/azure/static-web-apps/user-information?tabs=csharp#api-functions)

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS] MacOS Monterey 12.2.1
• Browser [e.g. chrome, safari]: Microsoft Edge
• Version [e.g. 22]: Version 98.0.1108.56

Running SWA CLI version 0.8.2

[manekinekko]

Thank you @egeyer for opening this issue. I apologize you had an unpleasant experience with the auth emulation.

We will investigate this regression bug on our end and keep you posted.

[aaronpowell]

Hi @egeyer,

I've had a look at it and have created a sample repo here: https://github.com/aaronpowell/swa-blazor-cli-bug

I was able to setup auth against the emulator, getting the following result back:

(it hits https://github.com/aaronpowell/swa-blazor-cli-bug/blob/main/Api/Secured.cs#L40 in the Function code path)

I tested on Windows (sorry I don't have a mac to test).

What I have noticed though is the IIdentity.IsAuthenticated is always returning true, even if I call it from curl with no custom headers (and the x-ms-client-principal header isn't present in the request) and the config route restrictions aren't being applied, so I'll have to have a look at that.

[aaronpowell]

Actually, it looks like it isn't flowing through the client principal info properly, the IsInRole test on IIdentity always returns false, so I'll have to have a look into that (essentially reporting false positives all over the place)

[aaronpowell]

Some more digging - I made a mistake, the route restrictions are applied if you write them correctly, whoops! So, SWA CLI will restrict based on config ✅

I think the problem is going to be with the local Azure Functions host and now SWA, because the header will pass-through correctly and can be manually decoded as shown here but it's not populating the ClaimsPincipal object. I'll start hunting that one down.

[aaronpowell]

After some debugging myself and then chatting with the Functions team, I've raised an issue on their GitHub repo to try and get some help on it (I'm struggling to get the end-to-end debugging working properly).

[manekinekko]

@aaronpowell any updates on this issue?

[aaronpowell]

@aaronpowell any updates on this issue?

I don't believe this is something that we'll be able to resolve in the SWA CLI as it is reliant on the Functions team addressing the bug.

[scottkuhl]

@aaronpowell any updates on this issue?

I don't believe this is something that we'll be able to resolve in the SWA CLI as it is reliant on the Functions team addressing the bug.

Is there a bug open for them you can point us to?

[aaronpowell]

https://github.com/Azure/azure-functions-core-tools/issues/2985