Provide access to parsed route parameters and method body parameters in authorization filters

[KirkMunro]

Maybe I'm just missing how this should be done, so if that is the case please let me know.

I use authorization filters to ensure that the calling user is authorized to make certain API calls. Sometimes these are simply via claims checks, other times they involve lookups in the database to verify that they have access to invoke the action. In the latter case, route parameters, query parameters, or values in a message body are used as part of the authorization logic. I can make calls within the individual API methods to do authorization, but I also have a unit test that ensures that all API endpoints are appropriately attributed with authorization attributes, and that doesn't pick up on authorization inside the code. I also prefer the authorization logic to be in authorization filters/attributes so that the endpoint logic is focused on what the endpoint is supposed to do.

The issue (which may end up being a feature request) is that it appears that parsing of request inputs (route parameters, query parameters, and message body parameters) has not been completed when an authorization filter is invoked. I can parse the data myself easily enough; however, I don't want to duplicate parsing, and for performance reasons I want input parameter values parsed once and only once.

Is it possible from within an authorization filter to access parsed route parameters, query parameters, and message body parameters? If not, is there an API in ASP.NET Core that can be invoked to do the parsing for the endpoint, such that it is done only once and accessible to an authorization handler? Or is there a better way to do this in another type of authorization filter/middleware that allows me to access inputs and use them for authorization purposes without manually parsing them myself and without duplicating parsing efforts?

I hope this was easy enough to follow. Thanks in advance.

[davidfowl]

@KirkMunro can you write a sample of the code you want to write?

[KirkMunro]

@davidfowl Here's a rough sample:

[AttributeUsage(AttributeTargets.Method)]
public class RequireSpecialAccessAttribute : Attribute, IAsyncAuthorizationFilter
{
    public async Task OnAuthorizationAsync(AuthorizationFilterContext context)
    {
        // This is all pseudocode to show the type of thing I want.
        // Imagine one of two scenarios:
        // 1. A GET method with a route of /api/v1/{accountId}/getTheThing or /api/v1/getTheThing?accountId={accountId}
        // 2. A POST method with a route of /api/v1/account/doTheThing and a message body of { "accountId" : "12345678" }
        // Note that there are multiple parameters I want to retrieve. I just mention one above for simplicity,
        // but in my case there are three parameters that I need to reference that come from the route or query string or body.
        var accountId = context.RouteParameter["accountId"];
        var otherParam = context.QueryParameter["otherParam"];
        // Or in the case of the message body, again, rough pseudocode to convey the idea
        var accountId = context.Body["accountId"];
        // IMPORTANT: Getting these values in this method should not require parsing the context.HttpContext.Request.Path
        // and context.ActionDescriptor.AttributeRouteInfo.Template (for GET) or context.HttpContext.Request.Body (for POST)
        // because ASP.NET parses these, and parsing twice should be unnecessary. So, is there a way to trigger the parsing
        // such that I can get these values without causing parsing to happen twice? Or a better way to do this?

        // What I have now is some code to use AttributeRouteInfo.Template and HttpContext.Request.Path and manually
        // Parse them for route parameters and query parameters (not comprehensive, wasteful, and only doing part of what
        // ASP.NET Core's built-in code does so well already. Ditto for HttpContext.Request.Body, I can use System.Text.Json
        // to parse that, which is simple enough, but should be unnecessary.
    }
}

[ApiController]
public class MyEndpointClass : ControllerBase
{
    [RequireSpecialAccess]
    [HttpPost("api/v1/account/doTheThing")]
    public async Task<ActionResult> Post(Request request, CancellationToken cancellationToken)
    {
        // In here I would simply have the code pertaining to what the request does. The authorization code
        // would be handled in the RequireSpecialAccessAttribute
    }
}

public class Request
{
    Guid AccountId { get; set; }
    int OtherParam { get; set; }
}

That should give you the general idea. I can have code in MyEndpointClass.Post that does authorization, but I want that code in an AuthorizationFilter or some other Authorization attribute, but without having to incur manual parsing logic and without taking a hit from parsing the inputs twice, unnecessarily (once from custom parsing logic, once from ASP.NET Core).

If you have additional questions or any of this is unclear, please let me know.

[davidfowl]

OK so some answers and more questions. The reason you can't get the parsed arguments is because model binding runs after authorization filters (https://learn.microsoft.com/en-us/aspnet/core/mvc/controllers/filters?view=aspnetcore-6.0#filter-types):

Only IAsyncActionFilters have access to the bound parameters.

The query string and route values are already available via HttpRequest.Query and HttpRequest.RouteValues respectively. The body on the other hand is not parsed into key value pairs (never has been and never will be 😄). That said, action filters do the right thing and provide access to the ActionArguments

Changing the order of execution would be a massive breaking change. Part of this design is to avoid expensive operations (model binding) until we know the endpoint is authorized.

If you want to write auth logic based on the data coming in from the request, then you'd need to run later in the pipeline (action filters).

[KirkMunro]

Thank you for your time on this.

The query string and route values are already available via HttpRequest.Query and HttpRequest.RouteValues respectively

I'm pretty sure I tried this and this wasn't the case, which is why I resorted to some manual parsing. I can check again though.

The body on the other hand is not parsed into key value pairs (never has been and never will be 😄)

Of course. I was greatly simplifying my example/pseudocode, and just not thinking through the whole thing at the time.

I didn't expect you would change the execution order. I was simply looking for a way to perhaps do model binding via an API call if the auth filter needs it, but I hadn't thought of simply moving the auth logic in the action filter. That might be just what I need. Going to give that a try now.

[davidfowl]

I'm pretty sure I tried this and this wasn't the case, which is why I resorted to some manual parsing. I can check again though.

I should mention these are "unparsed". You don't need to parse the entire query string or url template, but those parameters are strings that need to be bound and validated by the model binding system. In that sense, they are still "raw" and "unparsed".

[KirkMunro]

Since switching to an ActionFilter gave me what I need here, I'm going to close this. Thanks for the assistance @davidfowl. It simply didn't occur to me to use an ActionFilter as a post-binding authorization filter. Seems obvious now.