Authorization failure with resource - lack of documentation/warning/implementation

[optimizasean]

I am unable to find documentation explaining how to either create an Authorize Attribute that allows the resource to be set so that you can have implicit authorization where the policy can adapt more dynamically to generate authorization at the individual resource level. I also cannot find documentation stating why we should not do it so I am not sure if this is for a future release.

I need to extend the Authorize attribute to allow passing of resource which seems to be possible in the extensions of AuthorizeAsync which contain 2 overloads with parameters of object? resource. I have read through most all of the authorization code and cannot figure out why there is no overload in the Authorize attribute to pass data from razor pages such as route parameter data or how to retrieve this inside of a policy/requirement to have dynamic resource level authorization in razor pages.

If this is intentional due to some security concern or otherwise, this needs to be noted. Otherwise, there should be documentation on how to accomplish this as it seems like a fairly common use case to require denial per individual resources such as by permission granted by resource id. If this is intended to be added in a future feature, please let me know. There do not appear to be other issues covering this either.

[blowdart]

The reason you can't is that data binding happens after declarative authorization. This is a purposeful design decision, as some folks use classes/objects that have side effects during binding. There is no resource available at the time an attribute is processed.

You can, however, get access to route data etc, through the context object inside the policy you apply

[optimizasean]

It is good to know and makes sense due to request ordering. That also makes sense how to access the context used by the framework/platform you are programming towards through the context object it registers, however, it seems like the resource is neither though?

The article states 2 ways to access through either HttpContext or through AuthorizationFilterContext.

HttpContext is used in the WebApi model and AuthorizationFilterContext is used in the MVC model. I wrote a test to check and Blazor WebAssembly uses neither. Where can I find the documentation on how Blazor WebAssembly achieves this?

[blowdart]

@javiercn / @SteveSandersonMS can you point Sean to the blazor docs on this?

[optimizasean]

In the gitter chat covering aspnet/Blazor, @shawty Peter Shawty Shaw has written a blog post summarizing some of the findings of what we figured out relating to passing parameters with custom policy providers and a custom authorize attribute here: https://shawtyds.wordpress.com/2021/07/05/security-is-hard/

For passing data, here is the summary I wrote:
<AuthorizeView Policy/Role/...="something" Resource="resource" />, the resource can be anything that is either static or previously initialized. Good examples are the HttpContext, NavigationManager, Some singleton or something (think "injectables" and fixed data).

Razor auth testing page:

@page "/testing/auth"
@page "/testing/auth/{data}"

@inject NavigationManager navMan

<h1 class="text-4xl">Auth Resource Population</h1>

<AuthorizeView Policy="Test2" Resource="@navMan">
    <Authorized>
        <p>Authorized</p>
    </Authorized>
    <NotAuthorized>
        <p>Failure</p>
    </NotAuthorized>
</AuthorizeView>

<AuthorizeView Policy="Test3" Resource="@data">
    <Authorized>
        <p>Authorized</p>
    </Authorized>
    <NotAuthorized>
        <p>Failure</p>
    </NotAuthorized>
</AuthorizeView>

<AuthorizeView Policy="Test3" Resource="@str">
    <Authorized>
        <p>Authorized</p>
    </Authorized>
    <NotAuthorized>
        <p>Failure</p>
    </NotAuthorized>
</AuthorizeView>

@code {
    [Parameter] public string data { get; set; }

    public string str = "stringvalueshere";
    //
}

In Program.cs after builder.Services.AddOptions(); I wrote a few different policies I was using across pages to check to see what is and is not passable and what objects I can convert the resource into. I left these 3 since they seem to address the majority of contexts. Test1 was what I pulled from the docs and slightly changed (added a null check and debug statements). Test2 I was passing the NavigationManager for use in ripping route parameters by hand through string processing and determining the current page and other related data. Test3 I was passing in a string which was already declared to see if I could hardcode values on pages or use existing page level constants and similar data.

builder.Services.AddAuthorizationCore(options => {
    options.AddPolicy("Test1", policy =>
        policy.RequireAssertion(context => {
            if (context.Resource is HttpContext httpContext) {
                Console.WriteLine("TEST 1 HttpContext");
            } else if (context.Resource is AuthorizationFilterContext authorizationFilterContext) {
                Console.WriteLine("TEST 1 AuthorizationFilterContext");
            } else {
                Console.WriteLine("TEST 1 No Match");
            }
            if (context.Resource == null) {
                Console.WriteLine("TEST 1 null resource");
            }
            return true;
        })
    );
    options.AddPolicy("Test2", policy =>
        policy.RequireAssertion(context => {
            if (context.Resource is NavigationManager navigationManager) {
                Console.WriteLine("TEST 2 NavigationManager");
            } else {
                Console.WriteLine("TEST 2 No Match");
            }
            if (context.Resource == null) {
                Console.WriteLine("TEST 2 null resource");
            }
            return true;
        })
    );
    options.AddPolicy("Test3", policy =>
        policy.RequireAssertion(context => {
            if (context.Resource is string str) {
                Console.WriteLine("TEST 3 string");
            } else {
                Console.WriteLine("TEST 3 No Match");
            }
            if (context.Resource == null) {
                Console.WriteLine("TEST 3 null resource");
            }
            return true;
        })
    );
});

You have to use the AuthorizeView component like above and pass in some fixed thing (can pass navigation manager and tell policy where to rip route parameter and how to parse - string processing style - but route parameters are set after auth so you can't pass the already parsed chunk as either string or other value).

Also, according to the docs for further authorization you can do things like get the cascading parameter Task then do razor code like @if (await authState.claimswhateverLinq = routeparameter or dynamic data) { stuff and components here } or in some method on click of a button or on load or wherever, then AuthorizeAsync with resource using like IAuthorization or whatever that is and pass something in to a policy (so this resource could literally be anything since it would already exist at that point since this is "post auth" actions to deauth)?

It seems like it would be confusing to do that way and annoying to have all these random auth statements everywhere @if auth and so on, as well as to just stick everything in different levels of <AuthorizeView ...> components instead of something that could be accomplished at the page level if only the Authorize attribute took a resource such as a route parameter or some injected object from the page like the NavigationManager.

The only way I have successfully gotten resource based auth working would be to have your policies take the navigation manager from the resource in an AuthorizeView attribute and know how to parse the NavigationManager.Uri and convert the route parameters on its own to compare with your custom claims. Although I feel like this dodges some design decision since you could inject junk into the route parameter to maybe open a security hole? EDIT: Does it matter if you hack your own PC - i.e. the auth is only for visual on a client side application, the server should be the final authority to accept/reject requests. The server has access to the HttpContext so in the case of a web API of some kind, you can easily determine the user, their access rules, what they are accessing, and their intended action through the contents of a request and the endpoint it is sent to (you can add more data in request if necessary). I am focused specifically on Blazor WASM for this thread although resource based auth in MVC is probably related but views are controlled by the server, and not present on the user so the context and approaches are probably slightly different for authorization since MVC or Blazor server would require sanitization of the resource I think?

This seems to be the only possible way to accomplish this for resource based auth since you cannot pass route parameters and it is not the prettiest since the Authorize attribute does not accept resources. Can you advise if there is a better way?

[optimizasean]

Ideally for page level resource authorization based on a route parameter (the resource) you should be able to have something like this:

@page "/users/{id}/edit"

@attribute [Authorize(Policy = "CanEditUser", Resource = "@id")]

...other view code...

@code {
    [Parameter] public string id { get; set; }
    
    ....other background code...
}

and in Program.cs something like this:

builder.Services.AddAuthorizationCore(options => {
    options.AddPolicy("CanEditUser", policy =>
        policy.RequireAssertion(context => {
            //...Other auth code - add roles, add ...
            if (context.Resource is string id) {
                return auth.User.Claims.SingleOrDefault(x => x.Type == "UserResourceGrant" && x.Value == id) != null;
            }
            return false;
        })
    );
});

This doesn't work since the Authorize attribute does not accept a resource argument so instead you can wrap every page in the AuthorizeView component, but this seems to be a standard auth pattern for resource based authorization and the ideal way this should be accomplished. Are there plans to make something along these lines possible in the future? If not I would strongly suggest this to be added to the API.

Thanks for contacting us.

We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.