Introduce support for defining Authorization policies via Configuration

[DamianEdwards]

Spin-off of #39855 focusing on addition of top-level authorization configuration API.

Example matching Authorization changes to consider, allowing sharing of policies, etc.:

var builder = WebApplication.CreateBuilder(args);

builder.Authentication.AddJwtBearer();
builder.Authorization.AddPolicy("HasProtectedAccess", policy =>
    policy.RequireClaim("scope", "myapi:protected-access"));

var app = builder.Build();

app.MapGet("/hello", () => "Hello!");

app.MapGet("/hello-protected", () => "Hello, you are authorized to see this!")
    .RequireAuthorization("HasProtectedAccess");

app.MapGet("/hello-also-protected", () => "Hello, you authorized to see this to!")
    .RequireAuthorization("HasProtectedAccess");

app.Run();

The WebApplicationBuilder.Authorization property is typed as AuthorizationOptions allowing simple creation of policies and configuration of the default and fallback policies:

builder.Authorization.AddPolicy("HasProtectedAccess", policy => policy.RequireClaim("scope", "myapi:protected-access"));
builder.Authorization.DefaultPolicy = builder.Authorization.GetPolicy("HasProtectedAccess");

// Consider new methods to enable easily setting default/fallback policies by name
builder.Authorization.SetDefaultPolicy("HasProtectedAccess");
builder.Authorization.SetFallbackPolicy("HasProtectedAccess");

The WebApplicationBuilder would register an IConfigureOptions<AuthorizationOptions> in the services collection with a delegate that applies the settings.

Note this suggestion has a fundamental issue in that the AuthorizationOptions isn't designed to be mutated in this way, rather it should be configured via a callback registered in DI so that it runs at the appropriate time during app startup and composes with other code that wishes to configure it.

Perhaps instead the Authentication property should also read from configuration for authorization settings, and the Authorization property would be a new type that simply provides easy access to adding a configuration delegate, e.g.:

{
  "Authorization": {
    "DefaultPolicy": "HasProtectedAccess",
    "FallbackPolicy": "",
    "InvokeHandlersAfterFailure": true,
    "Policies": {
      "HasProtectedAccess": {
        "Claims": [
          { "scope" : "myapi:protected-access" }
        ]
      }
    }
  }
}

builder.Authentication.AddJwtBearer();
builder.Authorization.Configure(authz =>
{
    // Following is the code-based equivalent of config above
    authz.AddPolicy("HasProtectedAccess", policy => policy.RequireClaim("scope", "myapi:protected-access"));
    authz.DefaultPolicy = authz.GetPolicy("HasProtectedAccess");
});

Some other potential example policies as defined via configuration:

{
  "Authorization": {
    "DefaultPolicy": "HasProtectedAccess",
    "Policies": {
      "AuthenticatedUsers": {
        "AuthenticationRequired": true
      },
      "Employees": {
        "AuthenticationRequired": true,
        "Roles": [ "Employees" ]
      },
      "OnlyHomers": {
        "AuthenticationRequired": true,
        "UserName": "Homer"
      },
      "ApiClients": {
        "AuthenticationRequired": true,
        // Any unrecognized properties are auto-mapped as claims perhaps?
        "scope": [ "myapi:read", "myapi:protected-access" ]
      }
    }
  }
}

[DamianEdwards]

FYI @HaoK @Tratcher @davidfowl @captainsafia @jcjiang @blowdart

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[captainsafia]

Perhaps instead the Authentication property should also read from configuration for authorization settings, and the Authorization property would be a new type that simply provides easy access to adding a configuration delegate, e.g.:

I'm a fan of this approach:

• It's consistent with what we do for Authentication and makes it easier for users to reason about the mental model here.
• It provides us with a way to examine the authorization config for an application globally, which will help with some of the details in Automatically infer OpenApiSecuritySchemes from authentication configuration #39761 as I've been discovering.

I'm not aware of any implementation complexities that make the options-from-config approach not viable for authorization but @HaoK might be able to add some color here.

[HaoK]

Yeah config binding seems the cleanest for the properties (everything that's not a policy). Directly configuring an instance of AuthorizationOptions off of the builder seems more trouble than what's it worth. If you really want something like that, maybe just have an alternate dictionary of named policies, and settings, which you use in a regular options configuration of AuthorizationOptions, basically an AuthorizationOptionsBuilder property would be the analogy here.

In regards to authZ policies in config. Personally I would rather define that in code rather than muck around with json but seems ok as long as we don't go too insane with what requirements we support. We can certainly start with seeing what config definition of some simple policies look like, requiring the presence of a specific claim/role seems reasonably easy.

[DamianEdwards]

Ok so the feature would be IServiceCollection.AddAuthorization() will now also register an IConfigureOptions<AuthorizationOptions> that enables the configuration of AuthorizationOptions including defining policies from configuration.

A new property, WebApplicationBuilder.Authorization will be added that enables registering custom Action<AuthorizationOptions> configuration delegates that run in addition to the one added by WebApplicationBuilder.Authentication, essentially an alias for builder.Services.Configure(Action<AuthorizationOptions> configure).

Regarding the AuthZ policy configuration binding support, here's a strawman:

• DenyAnonymousAuthorizationRequirement
  Configuration property name RequireAuthenticatedUsers. Supports a single boolean value.

  "PolicyName": {
      "RequireAuthenticatedUsers": true
  },

• RolesAuthorizationRequirement
  Configuration property name Roles. Supports a single string value OR an array of string values (i.e. it looks for configuration keys like Authorization.PolicyName.Roles.0, Authorization.PolicyName.Roles.1, etc.).

  "PolicyName1": {
      "Roles": [ "RoleName1", "RoleName2" ]
  },
  "PolicyName2": {
      "Roles": "SingleRole"
  },

• ClaimsAuthorizationRequirement
  Configuration property name Claims. Supports an object where property names are claim types mapped to ClaimsAuthorizationRequirement.ClaimType and property values are a single string value OR an array of string values which are mapped to ClaimsAuthorizationRequirement.AllowedValues.

  "PolicyName1": {
      "Claims": {
          "scope": [ "scope1", "scope2", "scope3" ],
          "otherClaim": "claim value",
      }
  },

• NameAuthorizationRequirement
  Configuration property name RequiredName. Supports a single string value

  "PolicyName": {
      "RequiredName": "SuperAdminUser"
  },

[davidfowl]

Does this really add much over the call to AddAuthorization call?

[DamianEdwards]

Does this really add much over the call to AddAuthorization call?

The top-level WebApplicationBuilder.Authorization property doesn't no, we could not do that and just focus on the configuration binding aspect instead.

[HaoK]

+1 on just focusing on the configuration binding