Can Policy Based Authorization be more dynamic?

Question

Net Core policy authorization, however it is looking very static to me. Because in the Enterprise Application, there is an often need for new roles which will need new poli

Answer 1

The accepted answer is still quite limiting. It doesn't allow for dynamic values at the Controller and Action level. The only place a custom value could be added is in the requirement when the policy is added. Sometimes you need more fine grain control over the authorization process. A very common scenario is permission based security. Each controller and action should be able to specify the permissions required to access them. See my answer here for a more powerful solution that lets you use custom attributes to decorate your controllers and actions with any information you need while doing authorization.

Answer 2

I always recommend that people take a look @ the least privilege repo as it has some great examples of all the various approaches one can take with the new ASP.NET Core Authentication and Authorization paradigms.

Can this new policy base mechanism be more dynamic?

Yes, in fact it is more dynamic than the previous role based concepts. It allows for you to define policies that can be data driven. Here is another great resource for details pertaining to this. You can specify that an API entry point for example is protected by a policy (for example), and that policy can have a handler and that handler can do anything it needs to, i.e.; examine the current User in context, compare claims to values in the database, compare roles, anything really. Consider the following:

Define an entry point with the Policy

[Authorize(Policy = "DataDrivenExample")]
public IActionResult GetFooBar()
{
    // Omitted for brevity...
}

Add the authorization with the options that add the policy.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();    
    services.AddAuthorization(options =>
    {
        options.AddPolicy("DataDrivenExample",
                          policy => 
                          policy.Requirements.Add(new DataDrivenRequirement()));
    });    
    services.AddSingleton<IAuthorizationHandler, DataDrivenHandler>();
}

Then define the handler.

public class MinimumAgeHandler : AuthorizationHandler<DataDrivenRequirement>
{
    protected override void Handle(AuthorizationContext context, 
                                   DataDrivenRequirement requirement)
    {
        // Do anything here, interact with DB, User, claims, Roles, etc.
        // As long as you set either:
        //    context.Succeed(requirement);
        //    context.Fail();
    }
}

Is the idea entirely different?

It should feel very similar to the previous concepts that you're accustomed to with auth8 and authz.