Description
This issue will track all the various Authorization improvements we are looking at for 2.1.
Some initial thoughts:
From @davidfowl
We've had a bunch of feedback about our authz system with respect to flowing context from the authorize attribute to the authorization handler:
- Authorization infrastructure does not handle "per action permissions" use case well aspnet/Security#670
- Simplify writing custom authorization attributes aspnet/Mvc#5607
- Revisit PolicyProvider (large # permissions) scenarios/support aspnet/Security#917
- Authorization should be more dynamical and configurable aspnet/Security#1352
Today the Authorize attribute supports has enough metadata to describe the policy but it doesn't let you specify the resource (via IAuthorizeData). I think if we solve that, it might solve a bulk of the issues since people will be able to write custom attributes that flow the relevant context to the authorization handler.
Today that's only possible when doing imperative authz. I was thinking something like:
public interface IAuthorizeResource
{
object Resource { get; }
}
If the attribute implemented this, we would flow that as the resource to the handler. This way you implement permissions of whatever you please via resources.
From @rynowak
Look into providing overriding semantics in MVC, maybe a marker interface: IAuthorizeMetadata
. Any attributes that implement that interface on the endpoint could be flowed. Then it’s up to developers to build whatever they want. (Also look into flowing single objects vs many objects + requirements VS resources)
We will also look into making it possible to specify requirements via Attributes similar to imperative AuthZ so you don't have to preconstruct policies for attributes.
Misc other improvements:
- Consider supporting OR logic for policies: Add First Class Citizen Support of ORing Policies aspnet/Security#1356
- Consider enabling policies to be defined in configuration
- Make it easier to be able to display authZ failure reasons in an error page etc Question: How to retrieve the reason for an Authorization Policy Failure? aspnet/Security#1530
- Make it easier to pass parameters to policies, i.e. Can you create authorization policies without using magic strings? aspnet/Security#1689