Configuring the DataProtection options via appsettings.json file

[joymon]

Summary

Currently, it seems the DataProtection settings need to be configured via code. We are looking for support via appsettings.json or in general via configuration without recompiling the application for different deployment environment types.

Motivation and goals

As developers, we would like to code once and deploy in various environment types by tuning the configuration. Currently, the DataProtection configuration seems to support only via code. Though we can read configuration in a custom way, it would be great if the library provides the configuration options out of box.

In scope

Configure the DataProtection options from appsettings.json. In code, we will be adding services.AddDataProtection();

Out of scope

Risks / unknowns

How might developers misinterpret/misuse this? How might implementing it restrict us from other enhancements in the future? Also list any perf/security/correctness concerns.

Examples

services.AddDataProtection() - This will be loading the settings from the appsettings.json before defaulting to the values in the code.

ex: By default, the keys are stores at %USERPROFILE%\AppData\Local\ASP.NET\DataProtection-Keys. To change this folder we have to write code. This path should be configurable via appsettings.json

[davidfowl]

Can you provide more details? Are you just trying to change this one thing? Can you show what the code looks like today and what you'd like the setting to express?

[joymon]

The current way we are enabling the DataProtection is services.AddDataProtection() . When it runs on a desktop, it creates the key file %USERPROFILE%\AppData\Local\ASP.NET\DataProtection-Keys. When it runs in a load-balanced environment, it still creates files in the same place and fails as other machines has different keys. In load balanced environment, we have to point to a \SharedSMB path. It is possible via services.AddDataProtection().PersistKeysToFileSystem(new DirectoryInfo(@"\\SMBSharedPath")); but it needs code change. We are trying to use only services.AddDataProtection() and rest to be configurable from appsettings.json. Hope it clears

[davidfowl]

Sure, but you can write this code:

var path = configuration["DataProtection:Path"];
services.AddDataProtection().PersistKeysToFileSystem(path);

Then the code doesn't need to change.

[joymon]

Hi @davidfowl,
As mentioned in the original question, we can do the custom way by reading the configuration. But looking for an official / out-of-the-box way to read the config. Similar to the "Logging" section in appsettings.json. Does the DataProtection supports reading the configuration out of the box as of now?

[davidfowl]

Does the DataProtection supports reading the configuration out of the box as of now?

No, it doesn't. We could add support for this similar to logging yes. A few things that we'd need to design:

• What options can you configure
• How do you get this behavior by default? Is it opt-in or out.
• Is there a new API?

[joymon]

Response inline

• What options can you configure [Joy] We are looking for configuring the location of keys. But if you are designing I would recommend all the settings that can be done via code should be present in configuration
• How do you get this behavior by default? Is it opt-in or out. [Joy] Default behavior is to read from config similar to logging
• Is there a new API?[Joy] Not sure what you mean. Not expecting any new .Net class or method. The services.AddDataProtection() is expected to read from config

[blowdart]

The problem with using config is there is no common config between the providers, unlike the logging example @davidfowl talks about. The file path is unique to the file keyring provider, the key vault location is unique to keyvault etc.

Given there's a way to check environments already that would be the approach I'd take in my program.cs

[davidfowl]

I think it's reasonable to provide a way to configure this (answering some of these questions)

Thanks for contacting us.

We're moving this issue to the .NET 8 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.

[joymon]

The problem with using config is there is no common config between the providers, unlike the logging example @davidfowl talks about. The file path is unique to the file keyring provider, the key vault location is unique to keyvault etc.

Given there's a way to check environments already that would be the approach I'd take in my program.cs

@blowdart I agree that the settings are different for different providers. Though not exactly the same, the logging also works similarly. If we are logging into the console, no or very fewer options, but if it's to Azure App Insights, it requires an instrumentation key. I am not able to envision how the JSON should look as I am not aware of all the options. Once I am free from the busy schedule I will put some through. Hope by the time the current team get some time to look at this featue.