Extra error trapping for Entra BFF sample?

[guardrex]

We might want a bit more error trapping ...

https://github.com/dotnet/blazor-samples/blob/main/9.0/BlazorWebAppEntraBff/BlazorWebAppEntra/Program.cs#L153-L155

@halter73 @mikekistler Does adding ReplyForbiddenWithWwwAuthenticateHeaderAsync trapping on MicrosoftIdentityWebChallengeUserException and MsalUiRequiredException make sense to roll into ☝️ of the Entra BFF sample?

Something like ...

string accessToken;

try
{
    accessToken = await tokenAcquisition.GetAccessTokenForUserAsync(
        scopes, user: httpContext.User);
}
catch (MicrosoftIdentityWebChallengeUserException exception)
{
    await tokenAcquisition.ReplyForbiddenWithWwwAuthenticateHeaderAsync(
        exception.Scopes, exception.MsalUiRequiredException, httpContext.Response);
    return;
}
catch (MsalUiRequiredException exception)
{
    await tokenAcquisition.ReplyForbiddenWithWwwAuthenticateHeaderAsync(
        scopes, exception, httpContext.Response);
    return;
}

if (!string.IsNullorEmpty(accessToken))
{
    transformContext.ProxyRequest.Headers.Authorization = new("Bearer", accessToken);
}

---

Issue Details

⚠ Do not edit this section. It is required for issue processing.

• Content Source: dotnet/blazor-samples
• GitHub Login: @guardrex

[guardrex]

Hello @emmamones ... This issue is only about considering to add some extra error-trapping code. Unless something is opened as a patch code change request, we would ask that you open an issue from the bottom of the article using the Open a documentation issue link.

However, we have all of the guidance on how to configure the sample solution in the article at ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/security/blazor-web-app-with-entra?view=aspnetcore-9.0&pivots=non-bff-pattern

If you follow that, the sample should work. Of course, you must get the configuration correct in the Azure portal, too. I placed some remarks into the configuration text of the article to help devs get the Azure app registrations for the two projects set up correctly, and I provided examples using dummy values for the placeholders to help devs get the configuration correct. However, I can't really spend too much time in our article on that aspect. For example, we didn't intend to put up a tutorial with Azure portal screenshots. Devs should consult the Azure documentation if they need more detail. Also, we recommend public support channels for product support if you get stuck on something. We recommend ...

• Stack Overflow (tag: blazor)
• ASP.NET Core Slack Team
• Blazor Gitter

If you eventually come to find a bug in the article or want to make a suggestion on how to improve it, please open an issue using the Open a documentation issue from the bottom of the article.

[halter73]

At least for the CallApiForUserAsync call in ServerWeatherForecaster, while a 403 is probably better than a 500 from an uncaught exception, I think it'd be better yet to navigate to an access deniedpage since the browser will be expecting an HTML response when navigating to the /weather page and won't be able to do anything useful with the Www-Authenticate response header if there was one.

We could use httpContext.ForbidAsync() to do the redirect, but this would only work during pre-rendering when HttpContext.Response.HasStarted is false. If we care about special casing these exceptions, we should probably use NavigationManager to redirect to the access denied page so it works during Interactive Server rendering too.

Maybe @jmprieur or @keegan-caruso know if there are any exceptions that we could handle when using AddMicrosoftIdentityWebApp with a new challenge that requests additional scopes or reauthentication rather than going straight to a forbidden response. That said, this example doesn't try to do incremental consent or even restrict usage based on claims, so it might be okay to just redirect to the login URL any time token acquisition fails assuming that should be enough to fix it. I wouldn't want to introduce any infinite redirect issues though, so I'm fine redirecting to an access denied page. The user should have been challenged before trying to access the downstream token in most cases anyway.

I think using ReplyForbiddenWithWwwAuthenticateHeaderAsync makes more sense in the AddRequestTransform callback since we expect the WASM Client's HttpClient to be making the request. I'm not sure that the Www-Authenticate header is important, but we could still add a special-case to the ClientWeatherForecaster to redirect to the access denied or login endpoint based on weather it gets a 403 or 401 response.

The ClientWeatherForecaster change is probably a good idea even in cases where we can acquire a downstream token just to handle normal 401 and 403 responses forwarded from the MinimalApiJwt app. We'd also probably want to handle 302 login redirect that the CookieAuthenticationHandler might produce before even running the MapForwarder while we're at it. But starting in .NET 10, we'll be able to use app.MapForwarder(...).RequireAuthorization().DisableCookieRedirect() (API Proposal) to make the 302 login redirect a 401 instead.

I was going to suggest that we needed to still throw when setting a status code to prevent YARP from continuing to forward the request without an access token and overwrite any status code and header we set, but that's not necessary according to the YARP 2.0.0-rc1 changelog.

• Request transforms can now short-circuit requests and avoid proxying (Enable request transforms to reject requests  yarp#1923).
  • If you set the status code on the response to something other than 200 OK, or if you start writing to the response body, forwarding will be skipped.