Add AuthorizationPolicyCache

[halter73]

Background and Motivation

From @HaoK: We want to add a new metadata class which if applied to an endpoint, the authorization middleware will store the combined policy in this metadata to avoid recomputing the policy on every request (but only if the default policy provider is being used). The benefit for this being public is so anyone can benefit from this behavior by adding it to an endpoints metadata.

Proposed API

namespace Microsoft.AspNetCore.Authorization;

public interface IAuthorizationPolicyProvider
{
+    public bool CanCachePolicies => false;
}

public class AuthorizationMiddleware
{
+    public AuthorizationMiddleware(RequestDelegate next, IAuthorizationPolicyProvider policyProvider, IServiceProvider services);
}

Usage Examples

public class MyAuthorizationPolicyProvider : IAuthorizationPolicyProvider
{
    public bool CanCachePolicies => true;
}

Alternative Designs

Keep this internal for now and only use it from AuthorizationMiddleware.

Risks

We might want to change this class in the future and will be unable to make breaking changes since the metadata is now public.

---

PR for context: #43124
This is a follow up to the previously-approved RequireAuthorization overloads supporting inline policies: #39840

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[halter73]

API review questions?

1. What other than AuthorizationMiddleware and the new RequireAuthorization conventions is going to use this?
2. Does AuthorizationPolicyCache.Policy need to be both publicly readable and settable? Can just one or the other be made public? Neither?
3. On the issue @Kahbazi mentions that YARP might want to add it to its endpoints.
   1. Does YARP actually need to be able to configure or read the cached AuthorizationPolicy on the endpoint? That seems odd if it's just a cache. @Tratcher
   2. If it's an important scenario to add the policy cache to an endpoint but not to use it directly, can things like YARP just call RequireAuthorization on the endpoint to add it?
   3. Do we need an IEndpointConventionBuider extension method that adds AuthorizationPolicyCache and nothing else.
4. Should we seal this?

[halter73]

Also, do we think this a worthy use of publicly mutable metadata? @JamesNK what do you think?

[JamesNK]

I think this is abusing what the endpoint metadata collection is intended for.

[HaoK]

1. Not sure but basically anyone that wants to add authorization metadata, should also add this for perf
2. This probably can just be a marker class, with internal get/set for the middleware to consume.
3. Since there's no good reason (i think?) to ever turn this off for the default policy provider so we could just seal it I think.

I think this is abusing what the endpoint metadata collection is intended for.

This is purely a brainchild of @davidfowl and @DamianEdwards 😆

[Tratcher]

YARP makes endpoints and adds metadata to them:
https://github.com/microsoft/reverse-proxy/blob/e54839e924391e75d37928f21abe5987d4ab5990/src/ReverseProxy/Routing/ProxyEndpointFactory.cs#L100-L111

[halter73]

What about?

namespace Microsoft.AspNetCore.Authorization;

+ public static class AuthorizationCacheEndpointConventionBuilderExtensions
+ {
+     public static TBuilder WithAuthorizationCache<TBuilder>(this TBuilder builder) where TBuilder : IEndpointConventionBuilder;
+ }

The "correct" namespace is Microsoft.AspNetCore.Builder, but I want to hide this a little, because I expect most people will get this by calling some overload of RequireAuthorization(), but maybe not if they're using attributes.

[davidfowl]

There's one alternative to making it mutable but its a little crazy (good crazy). We do this optimization after we get #43225. We do this caching using Finally. We'd resolve the service in there and cache the "final" metadata if it's the default implementation (we can resolve the policy then and cache this immutable version of the metadata).

[halter73]

I love the Finally idea, but what about MVC? Or someone using auth attributes with minimal route handers? How does auth attach a Finally callback unless RequireAuthorization or the proposed WithAuthorizationCache method gets called?

[davidfowl]

I love the Finally idea, but what about MVC? Or someone using auth attributes with minimal route handers? How does auth attach a Finally callback unless RequireAuthorization or the proposed WithAuthorizationCache method gets called.

Does it need to? This is purely an optimization that happens in the 99% case:

• RequireAuthorization
• MVC controllers
• Razor pages

Other frameworks will work and can call the WithAuthorizationCache or users can call it in the worst case scenario (like on a group!).

For MVC and pages, we can just always call this internally, I assume the call will be smart enough to find the metadata and do the needful, otherwise it'll noop.