Shouldn't be necessary to define all policies upfront

[ghost]

using scopes for access (similar to github - see https://developer.github.com/v3/oauth/#scopes) I correlate e.g. ResourceAuthorize[Policy="READ-X"] with the existence of a claim with key="READ-X" (value= true resp. 1)

this works if I register all policies (READ-X, WRITE-X, READ-Y,...) upfront but try to avoid that with a custom policy provider using RequireClaim(name of policy) for policy creation during runtime

what do you think?

[DavidParks8]

That's a clever idea! While you could theoretically do that, I wouldn't recommend it. A basic implementation:

public class ClaimsAuthorizationPolicyProvider : IAuthorizationPolicyProvider
{
       public Task<AuthorizationPolicy> GetPolicyAsync(string policyName)
       {
           var builder = new AuthorizationPolicyBuilder();
           builder.RequireClaim(policyName);
           var policy = builder.Build();
           return Task.FromResult(policy);
       }
}

The implementation above would remove the capability of authorizing with complex business logic in a custom policy. It would tightly couple your authorization to the idea of "scopes", and it assumes that each scope would add a claim to the authenticated user. I have run into many business scenarios where a scope does not necessarily add a claim. While scopes are part of OpenID Connect and Oauth2, we can not guarantee that they will be used in the "next" big authorization framework.

I would suggest implementing all policies you want explicitly. It may add a bit of extra code in your startup class, but it forces you to really think about what you want to allow in your app, and it better prepares you for new architectures which may arise.

If we increase the complexity of my rudimentary implementation, we might be able to get the best of both worlds. You could make it interpret "special" string prefixes as claim policies, but otherwise use the old policy logic. For example "claim-read-X" could build a claim policy, but "read-X" might look for the read-X policy as defined in startup.cs.

[8snit]

Good points! I just looked at the aspnet/Security code and found a more a less equivalent issue. Their fix is straight forward, I can backport it if you want.

[DavidParks8]

Sure! Go for it and send a pull request. I'd be happy to review it.