Future AuthZ improvements list

[HaoK]

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

[rynowak]

My additional thoughts on this. We're looking at making the concept of an endpoint available at a low level from the dispatcher. Endpoints will have arbitrary metadata in an ordered list. This is the equivalent to what MVC does today by passing the action descriptor.

We'll probably also have a concept of active metadata which are metadata items that have been hydrated with the request context.

These might be useful/necessary building blocks for these things.

---

Additionally in the case of MVC, the current [Authorize] has some surprising behaviors compared to other filters. All authorize filters will execute rather than supporting overriding. Additionally, [AllowAnonymous] cannot be overridden and turns off all authorize attributes. These might be consistent with the past, but they don't really fit with the zen of MVC filters.

[HaoK]

Interesting, well if we have a new endpoint concept with a clean slate for metadata, we should probably just expose all of the basic building blocks

1. Building the ClaimsPrincipal, need to end up with 0 or more authentication schemes. If none are specified, we continue to use the default user aka httpContext.User, otherwise we build a merged user via authenticating all of the schemes. We could manifest this with a series of [Authenticate(scheme)] attributes.

2. Specifying the Authorization requirements, today the metadata only targets policies, but we could have [Authorize(typeof(MyRequirement), typeof(MyOtherRequirement)]

Some examples:

[Authorize]

Would behave the same as today (using some default policy which relies on context.User, and still only does RequireAuthenticatedUser by default

[Authenticate("Bearer")]
[Authorize]

Would use the Bearer scheme and only require that it exists.

[Authenticate("Bearer", "Cookie")]
[Authorize(typeof(RequireAdminClaim)]

Would use the merged Bearer Cookie schemes and require an admin claim.

[Tratcher]

Which challenge would you issue?

[HaoK]

All of them, its not any different than today

[Tratcher]

Challenging both Bearer and Cookie is nonsensical.

[HaoK]

Not disagreeing, but today if you have a policy that has Bearer and Cookies, that's what it does today as well

[HaoK]

Unless we want to eliminate being able to specify multiple schemes entirely... that's an option that would simplify things...

[davidfowl]

Not disagreeing, but today if you have a policy that has Bearer and Cookies, that's what it does today as well

It does? What happens as a result? Don't they stomp on each other?

[HaoK]

Yeah they do, last one wins, multiple auth schemes in policies has always been a bit weird

[Tratcher]

Some are compatible like Bearer, Basic, and Windows.

[Eilon]

@HaoK please log new issues for any 2.1.0 proposals.

[hmvs]

@HaoK Is it going to be a part of 2.1 release?