AspNet Core использует в памяти репо для защиты данных при работе в IIS

Я запускаю производственный сервер (Windows Server 2012) с веб-сайтом AspNet Mvc Core RC1.

В журналах я вижу следующее:

Neither user profile nor HKLM registry available. Using an ephemeral key repository. Protected data will be unavailable when application exits.

После проверки исходного кода DataProtection я обнаружил проблему следующим вызовом метода:

Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)

По какой-то причине это, вероятно, возвращает нуль на сервере. У меня нет специальной настраиваемой конфигурации, и я прочитал docs, поэтому я думал, что по умолчанию будет работать.

Я думаю, проблема связана с тем, что веб-сайт IIS не работает в определенном пользовательском контексте, но я понятия не имею, как подтвердить или исправить это. Мой сайт настроен с собственным пулом.

В стороне: результат запуска хранилища в хранилище для хранения ключей заставляет их перерабатывать всякий раз, когда приложение выходит, что очень раздражает и даже не предназначено для использования в производственных средах.

Ответ 1

Профиль пользователя должен быть загружен в конфигурации IIS.

Откройте IIS, щелкните правой кнопкой мыши Пулы приложений, затем Расширенные настройки. И установите для "Загрузить профиль пользователя" значение true. Перезапустите приложение, и оно должно работать идеально.

Ответ 2

Ключи защиты данных, используемые приложениями ASP.NET, хранятся в кустах реестра, внешних по отношению к приложениям. При запуске приложения в качестве идентификатора AppPool необходимо создать куст реестра для каждого AppPool, используемого с приложением ASP.NET Core.

Для автономных установок IIS вы можете использовать сценарий PowerShell Data Protection для каждого пула приложений, используемого с приложением ASP.NET Core. Ключи будут сохранены в реестре.

Как четко указано в журналах, поскольку куст реестра, который ищет защита данных, не существует, ключи не будут сохранены на диске. Вместо этого они будут эфемерными и будут жить только в памяти.

В сценариях веб-фермы приложение можно настроить на использование пути UNC для хранения своего набора ключей защиты данных. По умолчанию ключи защиты данных не шифруются. Вы можете развернуть сертификат x509 на каждом компьютере для шифрования набора ключей.

См. Официальные документы ASP.NET Core для получения дополнительной информации.

Ответ 3

Взгляните на это из репозитория DataProtection Git.

Короче говоря, в IIS есть ошибка, которая никогда не может быть исправлена и препятствует правильной настройке реестра для ключей DataProtection. Существует сценарий powershell для правильной настройки реестра вручную, чтобы он работал для AspNet Core. После запуска сценария для каждого пула приложений, который вы используете для приложений AspNet Core, эти приложения будут работать так, как задумано.

Ответ 4

Те, кто находится в размещенной среде, где права доступа очень ограничены, могут вместо этого использовать PersistKeysToFileSystem. Добавление следующего списка в Startup.cs решит вашу проблему:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(@"\\server\share\directory\"));
}

Вы можете изменить строку пути в соответствии с вашими потребностями. Также проверьте ProtectKeysWith, если вы хотите настроить систему для защиты ключей в состоянии покоя, вызвав любой из API-интерфейсов конфигурации ProtectKeysWith *.