Multiple dataprotection providers for migration/fallback

Is your feature request related to a problem? Please describe.

I’m not sure if this is possible at all since the documentation feels rather scarce when it comes to changes to the data protection stores, but we have 2 different migration issues here with changing Data Protection providers:

1. We want to migrate our existing DataProtection keys from one data store to another, relying on the implementation itself to do the work of creating and storing the missing keys rather than us having to work out exactly how the format is different between providers.
2. We’ve realised after-the-fact that we should have had set the application name for the DataProtection config since we now want to share the existing keys with multiple applications. Adding a name now seems to log out all users which is really not a viable option on a consumer website (last time it happened when we migrated from ASP.NET to Core, we were getting emails about a “bug” and forgotten password issues for months).

Describe the solution you’d like

If any of the above is already possible, it’d be ideal to include it in the documentation.

If it’s not already possible, ideally we’d like to see the following features:

1. The ability to add multiple DataProtection key stores, with the expectation that the key stores have their keys reconciled (maybe have multiple ReconciliationStrategies, such as merge and override?) and maintained at a synchronised state.
2. The ability to either add a new ApplicationName for data protection with the expectation that keys referring to the old name are migrated, or, similar to above, the ability to add multiple application names and have identical keys maintained for both names.
3. Pertaining to #1, if there are already multiple key stores defined, the ability to use a synced key store for fallback might be a welcome addition in certain scenarios such as in the case of geo-replicated Kubernetes clusters, but this is really more of an optional idea if there are already multiple key stores anyway.

These could be either implemented via a new IKeyManager or IXmlRepository store, or implemented directly in the core of the data protection system. I can see pros on both sides of this issue.

[madelson]

@GrabYourPitchforks regarding your suggested configuration approach , for creating the nested protector instances would you need to create nested instances in their own service containers?

I’m imagining something like this:

ServiceCollection services1 = new();
services1.AddDataProtection(/* configuration 1 */);
ServiceProvider provider1 = services1.BuildServiceProvider();
IDataProtectionProvider dataProtectionProvider1 = (IDataProtectionProvider)provider1.GetRequiredService(typeof(IDataProtectionProvider));

... // repeat for configuration2

// on the main application service collection
services.AddSingleton(typeof(IDataProtectionProvider), _ => new DelegatingDataProtectionProvider(dataProtectionProvider1, dataProtectionProvider2));

I might have expected to be able to use DataProtectionProvider.Create, but that method seems to limit your persistence/protection options.

[GrabYourPitchforks]

enhancement seems like an appropriate label. The extensibility hooks to allow this already exist. If this is a common enough scenario then it’d be useful to provide a vetted implementation in-box.