AuthN Config V2 -> HotReload Aware Authentication settings in dev mode.

[seantleonard]

Why make this change?

• Closes Hot Reload Authentication settings #1969 which tracks making DAB's authentication configuration hot-reload aware.

What is this change?

The following changes are only honored in development mode when testing locally using "Hot Reload"

• Introduces ConfigureAuthenticationV2() in startup.cs which wires up all DAB supported Authentication providers:
  • EasyAuth AppService/StaticWebApps
  • JWT (AzureAD/EntraID, and Custom OAuth2 providers)
• Utilizes change tokens within RuntimeConfigProvider and RuntimeConfigLoader to signal IOptionsMonitor that authentication settings have changed.
• Update ClientRoleHeaderAuthenticationMiddleware to emit condensed and more helpful log event for each request:

AuthN state: Anonymous. Role: Anonymous. Scheme: Bearer

• The Scheme metadata in the log event will indicate which scheme the authentication handler is using. This will help users observe that hot reload has succeeded.

How was this tested?

• Manual tests with real identity provider that we don't have in our pipelines. This is a development mode only feature.

Scenario 1 - Swap JWT Provider Details

1. Open the dab-config.json file used by DAB.
2. Ensure the config sets Mode: Development
3. Modify the Authentication section to include JWT authN with your AzureAD provider (issuer/audience).
4. Send a request which requires validation: see HTTP 200
5. Modify the Authentication section with an "invalid" audience
6. Select "SAVE" -> hot reload will occur
7. Send a new request using the previously used token -> HTTP 401 invalid issuer.

Scenario 2 - Swap from JWT to Simulator

1. Open the dab-config.json file used by DAB.
2. Ensure the config sets Mode: Development
3. Modify the Authentication section to include JWT authN with your AzureAD provider (issuer/audience).
4. Send a request which requires validation: see HTTP 200
5. Modify the Authentication section by removing the jwt section with audience/issuer and leave only the "Provider" property
6. Modify the authentication provider property to be Simulator
7. Select "SAVE" -> hot reload will occur
8. Send a new request using the previously used token -> authenticated

Usage of ChangeTokens versus EventHandler in this specific workstream:

The objective was to trigger the IOptionsMonitor within the JwtBearerHandler to detect changes to authentication programmatically (as opposed to the out-of-box change detection for a bound configuration file such as appsettings.json, which we don't use). In order to alert the IOptionsMonitor that a change has occurred, I needed to register:

services.AddSingleton<IOptionsChangeTokenSource<JwtBearerOptions>>(new JwtBearerOptionsChangeTokenSource(runtimeConfigProvider));

which is this resolved via DI in the OptionsMonitor class:
https://github.com/dotnet/runtime/blob/88397049d6aa2c8505bd11309ddd314169e3f73f/src/libraries/Microsoft.Extensions.Options/src/OptionsMonitor.cs#L31-L53

        public OptionsMonitor(IOptionsFactory<TOptions> factory, IEnumerable<IOptionsChangeTokenSource<TOptions>> sources, IOptionsMonitorCache<TOptions> cache)
        {
            _factory = factory;
            _cache = cache;

            void RegisterSource(IOptionsChangeTokenSource<TOptions> source)
            {
                IDisposable registration = ChangeToken.OnChange(
                          source.GetChangeToken,
                          InvokeChanged,
                          source.Name);

                _registrations.Add(registration);
            }

            // The default DI container uses arrays under the covers. Take advantage of this knowledge
            // by checking for an array and enumerate over that, so we don't need to allocate an enumerator.
            if (sources is IOptionsChangeTokenSource<TOptions>[] sourcesArray)
            {
                foreach (IOptionsChangeTokenSource<TOptions> source in sourcesArray)
                {
                    RegisterSource(source);
                }

once our runtimeconfigloader detects a file change, it signals the provider that new runtimeconfig is available. Then the RuntimeConfigProvider (which is the service resolved via DI in most of our classes already) can signal the change token whose listener is the OptionsMonitor via registering the IOptionsChangeTokenSource.

This mechanism was not as intrusive to our services' constructors:

1. No need to resolve IOptionsMonitorCache<jwtBearerOptions> in our RuntimeConfigProvider or RuntimeConfigLoader class constructors. Updating the optionsmonitorcache would be( i tested this) the manual way of changing IOptionsMonitor<JwtBearerOptions> used by the JwtBearerHandler, but this didn't work because of the next bullet point:
   2. I made a judgement call that injecting IoptionsmonitorCache<jwtBearerOptions> into either of the two referenced classes seemed to leak implementation details of the provider/loader and wouldn't be straightforward without more time consuming and costly refactors:
   - Because both the provider/loader are manually instantiated in Startup::ConfigureServices and don't have the opportunity to resolve services via DI.
   - Because we'd then need to make even more cascading changes in the test projects to accommodate setting up the ioptionsmonitorcache object to then be added to our mock runtimeconfigprovider/loader objects.

The event-handlers we have recently added don't fit this specific use case of updating the underlying authentication configuration. In addition to the above design decisions, I didn't identify a solution where we could subscribe the JwtBearerHandler's OptionsMonitor to an eventhandler signal to notify that a change occurred. I pursued using the built-in mechanism of change detection for optionsmonitor provided to us via IOptionsChangeTokenSource.

[seantleonard]

/azp run

[seantleonard]

/azp run

[Aniruddh25]

In V1, we added authentication conditionally. But in V2, we are adding all schemes unconditionally. Is there benefit in keeping V1 around? If not, to keep the code base simple, is it better to do V2 irrespective of whether its a hot reload scenario or not?

[Aniruddh25]

nit: rename to indicate this function also handles signaling the change token. Currently, it says send event notification only.

[Aniruddh25]

This setup of httpContext.User is the only required change for hot reload in this file,right? Is my understanding correct that the rest of the changes in this file are good to have but not really relevant to hot reload?

I dont mind the changes but trying to understand how the value of scheme affects hot reload..

[seantleonard]

We need all the code in this file and on lines that precede this code. The following line is important because we must pass scheme to authenticateAsync to ensure the proper authentication handler is used. Scheme is determined using the runtime config. If the provider changes in runtime config, DAB must resolve that change and ensure the request is authenticated using the hotreloaded scheme.

await httpContext.AuthenticateAsync(scheme);

[Aniruddh25]

Suggested change

	/// Get RuntimeConfigProvider to use as the change event source.
	/// Get RuntimeConfigProvider to use as the change token source.

[Aniruddh25]

Suggested change

	/// to enable compatility with HotReloading authentication settings.
	/// to enable compatibility with HotReloading authentication settings.

[Aniruddh25]

Suggested change

	/// <param name="provider">Runtime configured identity provider name. This is different that authentication scheme name because
	/// <param name="provider">Runtime configured identity provider name. This is different than authentication scheme name because

[Aniruddh25]

LGTM, left few nits and questions. Thanks for this change.

[sezal98]

should we make these constants and use case-insensitive matching?

[abhishekkumams]

LGTM, thanks for the quick update and clarifying doubts.