Asp.Net Core WebApi - AWS ECS Cluster Authentication failure

[jcrawfor74]

Asp.Net Core WebApi - AWS ECS Cluster Authentication failure

[commonsensesoftware]

Apologies for the long overdue response. This issue somehow slipped through my email cracks and I just noticed it while scanning through the issue log.

I going to see if I can give you some pointers that may help you out, but - honestly - there is no part of API Versioning involved here. API Versioning does not define any custom routes or security. That is completely orthogonal and defined by you.

I don't know how the custom authentication scheme you have defined works. The difference in environment is likely either due to how you authenticate as a relying party or due to configuration differences. It's commonplace for an application to outsource authentication as a relying party and let something else handle it (ex: OIDC). The fact that you are seeing 401 means that whatever your scheme uses to verify authentication is not finding what it expects.

Since it is a custom mechanism, it is also possible that the logic is incorrect. 401 (Unauthorized) really means the client is unauthenticated. The server is saying "I don't know who you are". A 401 response must return one or more challenges in the WWW-Authenticate header that tells the client which methods they can use to authenticate. If a client is authenticated, but not authorized, they will (or should) received a 403 (Forbidden). A 403 response is terminal and cannot be challenged. This is the server say "I know who you are, but I still say no." This can result in strange edge cases if there is more than one challenge method that could yield different authorization. Most servers only return one challenge, but it doesn't have to. Unfortunately, there isn't really a mechanism (that I'm aware of) that can indicate that the server should challenge the client for a more elevated form of authentication.

It's not evident how authentication or authorization is enforced, but it appears you are mixing and matching controllers with Minimal APIs. This is allowed, but note that not all of the controller configuration and settings apply to Minimal APIs. Core services and middleware should carry through to Minimal APIs, but action filters and other settings will not. Based on the error message provided, it appears that your authorization policy does not allow an anonymous user a la DenyAnonymousAuthorizationRequirement. Keep in mind that an anonymous user can still be an authenticated user. That can be a bit confusing. Windows, for example, doesn't have a concept of no authentication. There is a special security principal called NT_AUTHORITY/ANONYMOUS LOGON, which is commonly used for web identities that don't require additional authentication. That may not be your situation, but I want to highlight that you might be getting a JWT for an authenticated, but anonymous user which does not possess the required claims. You may need to adjust your policy or security requirements for that specific endpoint.

For a health point, you don't need any content. If you want HTML, go for it, but you don't need any content. You could also have the Minimal API serve the content straight from disk. It's not clear where the HTML comes from, but if it's static, it's probably easier to manage as a standalone file and then just serve it in the API response, while also making sure you indicate the content is text/html, which I didn't see.

Regardless of choice, you can opt out of the API Explorer and security with:

endpoints.MapGet("/welcome", context => context.Response.WriteAsync(welcome))
         .ExcludeFromDescription()
         .AllowAnonymous();

---

Aside

I couldn't help but notice a few other, tangential items from the information you provided.

1. Do not use Task.Result - ever. If you absolutely have no other option, then the best escape hatch is Task.GetAwaiter().GetResult(). That will even work for a void return.
2. Since you're mixing and matching controllers with Minimal APIs, if there other APIs they will not be picked up by provider.ApiVersionDescriptions. You should use app.DescribeApiVersions().
   • Minimal APIs are defined after the DI container has been created; this ensures they are picked up
   • The results and process are otherwise the same
3. It's not wrong, but options.DefaultApiVersion = new ApiVersion(1, 0); is redundant
   • The default configuration is ApiVersioningOptions.DefaultApiVersion = ApiVersion.Default;
   • ApiVersion.Default = new ApiVersion(1.0)

[commonsensesoftware]

It would seem that you have resolved your issue or decided to otherwise not pursue further assistance. If that is not the case, feel free to reopen the issue.