Key storage providers

By default the data protection system employs a heuristic to determine where cryptographic key material should be persisted. The developer can override the heuristic and manually specify the location.

备注

If you specify an explicit key persistence location, the data protection system will deregister the default key encryption at rest mechanism that the heuristic provided, so keys will no longer be encrypted at rest. It is recommended that you additionally specify an explicit key encryption mechanism for production applications.

The data protection system ships with several in-box key storage providers.

File system

We anticipate that many apps will use a file system-based key repository. To configure this, call the PersistKeysToFileSystem configuration routine as shown below. Provide a DirectoryInfo pointing to the repository where keys should be stored.

sc.AddDataProtection()
       // persist keys to a specific directory
       .PersistKeysToFileSystem(new DirectoryInfo(@"c:\temp-keys\"));

The DirectoryInfo can point to a directory on the local machine, or it can point to a folder on a network share. If pointing to a directory on the local machine (and the scenario is that only applications on the local machine will need to use this repository), consider using Windows DPAPI to encrypt the keys at rest. Otherwise consider using an X.509 certificate to encrypt keys at rest.

Azure and Redis

The Microsoft.AspNetCore.DataProtection.AzureStorage and Microsoft.AspNetCore.DataProtection.Redis packages allow storing your data protection keys in Azure Storage or a Redis cache. Keys can be shared across several instances of a web app. Your ASP.NET Core app can share authentication cookies or CSRF protection across multiple servers. To configure on Azure, call one of the PersistKeysToAzureBlobStorage overloads as shown below.

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
        .PersistKeysToAzureBlobStorage(new Uri("<blob URI including SAS token>"));

    services.AddMvc();
}

See also the Azure test code.

To configure on Redis, call one of the PersistKeysToRedis overloads as shown below.

public void ConfigureServices(IServiceCollection services)
{
    // Connect to Redis database.
    var redis = ConnectionMultiplexer.Connect("<URI>");
    services.AddDataProtection()
        .PersistKeysToRedis(redis, "DataProtection-Keys");

    services.AddMvc();
}

See the following for more information:

• StackExchange.Redis ConnectionMultiplexer
• Azure Redis Cache
• Redis test code.

Registry

Sometimes the app might not have write access to the file system. Consider a scenario where an app is running as a virtual service account (such as w3wp.exe's app pool identity). In these cases, the administrator may have provisioned a registry key that is appropriate ACLed for the service account identity. Call the PersistKeysToRegistry configuration routine as shown below. Provide a RegistryKey pointing to the location where cryptographic keys/values should be stored.

   sc.AddDataProtection()
       // persist keys to a specific location in the system registry
       .PersistKeysToRegistry(Registry.CurrentUser.OpenSubKey(@"SOFTWARE\Sample\keys"));

If you use the system registry as a persistence mechanism, consider using Windows DPAPI to encrypt the keys at rest.

Custom key repository

If the in-box mechanisms are not appropriate, the developer can specify their own key persistence mechanism by providing a custom IXmlRepository.