Add IAuthenticationConfigurationProvider.GetAuthenticationConfiguration

[captainsafia]

To support reading default schemes from configuration, we need to add an API to IAuthenticationConfigurationProvider​ that allows us to extract the root Authentication​ property from configuration.

The PR also adds a set of shared constants for use in the user-jwts CLI and the runtime with regarding to accessing these configuration keys.

Risks
Low, we've discussed adding this is a follow-up item from preview5.

Pull Request
#41987

Proposed API

namespace Microsoft.AspNetCore.Authentication;

public interface IAuthenticationConfigurationProvider
{
+    public IConfiguration Authentication { get; }
}

namespace Microsoft.AspNetCore.Authentication;

public static class AuthenticationConfigurationProviderExtensions
{
+    public static IConfiguration GetSchemeConfiguration(this IAuthenticationConfigurationProvider provider, string authenticationScheme);
}

Sample Usage
An end-user can implement a custom IAuthenticationConfigurationProvider to point to where the top-level configuration key in their application is.

public class MyAuthenticationConfigurationProvider : IAuthenticationConfigurationProvider
{
    private IConfiguration _configuration;
 
    public DefaultAuthenticationConfigurationProvider(IConfiguration configuration)
    {
        _configuration = configurationRoot;
    }
 
    public IConfiguration Authentication => _configuration.GetSection("MyCustomAuthName");
}

Sample Config

{
  "MyCustomAuthName": {
    "DefaultScheme": "ClaimedDetails",
    "Schemes": {
      "Bearer": {
        "Audiences": [
          "https://localhost:7259",
          "http://localhost:5259"
        ],
        "ClaimsIssuer": "dotnet-user-jwts"
      },
      "ClaimedDetails": {
        "Audiences": [
          "https://localhost:7259",
          "http://localhost:5259"
        ],
        "ClaimsIssuer": "dotnet-user-jwts"
      }
    }
  }
}

In our ConfigureOptions implementation, we use the GetSchemeConfiguration extension method to access individual schemes

internal sealed class JwtBearerConfigureOptions : IConfigureNamedOptions<JwtBearerOptions>
{
    public void Configure(string? name, JwtBearerOptions options)
    {
        var configSection = _authenticationConfigurationProvider.GetSchemeConfiguration(name);
    }
}

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[davidfowl]

Why does this need the schemes as a first class property?

[captainsafia]

Why does this need the schemes as a first class property?

It makes sense to me to have every key we support under Authentication as a first-class property. I suppose on alternative is to store an Authentication:Schemes key but it made sense to keep the properties separate and leave it up to the implementor to combine as needed.

[davidfowl]

It makes sense to me to have every key we support under Authentication as a first-class property. I suppose on alternative is to store an Authentication:Schemes key but it made sense to keep the properties separate and leave it up to the implementor to combine as needed.

Do we need a strongly typed object model on authentication configuration for every top level configuration property? I think we should keep this type simple. It's a way to get access to the top level auth config section, and the config section for a scheme. Otherwise, it's no longer an interface but instead a poco like AuthenticationOptions.

GetAuthenticationConfiguration should be a property.

[halter73]

API Review Notes:

• Do we like properties instead of methods?
  • Yes.
• Should we suffix the property names with "Configure"?
  • No. It's in the interface name already. This only shows up if you resolve it from DI, so you should know what the type does.

namespace Microsoft.AspNetCore.Authentication;

public interface IAuthenticationConfigurationProvider
{
-    public IConfiguration GetAuthenticationConfiguration();
+    public IConfiguration Authentication { get; }
+    public IConfiguration AuthenticationSchemes { get; }
}

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[halter73]

Here's the proposed diff from the originally approved API if I'm reading this correctly:

namespace Microsoft.AspNetCore.Authentication;

public interface IAuthenticationConfigurationProvider
{
    public IConfiguration Authentication { get; }
-    public IConfiguration AuthenticationSchemes { get; }
}

+ public static class AuthenticationConfigurationProviderExtensions
+ {
+    public static IConfiguration GetSchemeConfiguration(this IAuthenticationConfigurationProvider provider, string authenticationScheme);
+ }

Is there a benefit of calling _authenticationConfigurationProvider.GetSchemeConfiguration(name); over _authenticationConfigurationProvider.GetSection($"Scheme:{name}")? Is it just trying to get rid of the magic string? Seems reasonable

It does seem a little weird to call _authenticationConfigurationProvider.Authentication for the parent config section and call _authenticationConfigurationProvider.GetSchemeConfiguration(name) for the subsection because one calls out Configuration in the name and the other doesn't. Should _authenticationConfigurationProvider.Authentication be _authenticationConfigurationProvider.AuthenticationConfiguration instead?

[captainsafia]

Is there a benefit of calling _authenticationConfigurationProvider.GetSchemeConfiguration(name); over _authenticationConfigurationProvider.GetSection($"Scheme:{name}")? Is it just trying to get rid of the magic string? Seems reasonable

Yep, and to provide an abstraction over getting the scheme from the provider, which we will be using in all the different options from config implementations (e.g. JwtBearerConfigureOptions, CookieConfigureOptions)

Should _authenticationConfigurationProvider.Authentication be _authenticationConfigurationProvider.AuthenticationConfiguration instead?

Sure. That works.

[halter73]

Approved API (relative to what's currently checked in):

namespace Microsoft.AspNetCore.Authentication;

public interface IAuthenticationConfigurationProvider
{
-    IConfiguration GetAuthenticationSchemeConfiguration(string authenticationScheme);
+    IConfiguration AuthenticationConfiguration { get; }
}

+ public static class AuthenticationConfigurationProviderExtensions
+ {
+    public static IConfiguration GetSchemeConfiguration(this IAuthenticationConfigurationProvider provider, string authenticationScheme);
+ }

[captainsafia]

Closed via #41987.