it-swarm.com.de

AspNet Core verwendet im Arbeitsspeicher Repo für den Datenschutz beim Ausführen IIS

Ich betreibe einen Produktionsserver (Windows Server 2012) mit einer AspNet Mvc Core RC1-Website.

In den Protokollen sehe ich Folgendes:

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

Nachdem ich den Quellcode für DataProtection untersucht hatte, verfolgte ich das Problem mit dem folgenden Methodenaufruf:

Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)

Dies gibt wahrscheinlich aus irgendeinem Grund Null auf dem Server zurück. Ich habe keine spezielle benutzerdefinierte Konfiguration und ich habe docs gelesen. Ich dachte, die Standardeinstellung würde funktionieren.

Ich denke, das Problem liegt darin, dass die IIS-Website nicht in einem bestimmten Benutzerkontext ausgeführt wird, aber ich habe keine Ahnung, wie ich dies bestätigen oder beheben kann. Meine Website ist mit einem eigenen Pool konfiguriert.

Nebenbei bemerkt: Das Ergebnis der Ausführung eines Speicher-Repositorys zum Speichern von Schlüsseln führt dazu, dass sie immer dann erneut verwendet werden, wenn die Anwendung beendet wird.

25
mrahhal

Das Benutzerprofil sollte in IIS Konfiguration geladen werden.

Öffnen Sie IIS, klicken Sie mit der rechten Maustaste auf Anwendungspools und dann auf Erweiterte Einstellungen. Und setzen Sie "Benutzerprofil laden" auf "true". Starten Sie Ihre App neu und es sollte einwandfrei funktionieren.

22
mrahhal

Von ASP.NET-Anwendungen verwendete Datenschutzschlüssel werden in Registrierungsstrukturen außerhalb der Anwendungen gespeichert. Wenn Sie Ihre Anwendung als AppPool-Identität ausführen, müssen Sie eine Registrierungsstruktur für Every AppPool erstellen, die mit einer ASP.NET Core-Anwendung verwendet wird.

Für Standalone-Installationen mit IIS können Sie das Data Protection PowerShell-Skript für jeden Anwendungspool verwenden, der mit einer ASP.NET Core-Anwendung verwendet wird. Die Schlüssel bleiben in der Registrierung erhalten.

Wie in den Protokollen eindeutig angegeben, da die Registrierungsstruktur, nach der Data Protection sucht, nicht vorhanden ist, werden die Schlüssel nicht auf der Festplatte gespeichert. Stattdessen sind sie nur vergänglich und leben nur im Speicher.

In Webfarmszenarien kann eine Anwendung so konfiguriert werden, dass ein UNC-Pfad zum Speichern des Datenschutzschlüsselrings verwendet wird. Standardmäßig werden die Datenschutzschlüssel nicht verschlüsselt. Sie können auf jedem Computer ein x509-Zertifikat bereitstellen, um den Schlüsselring zu verschlüsseln.

Weitere Informationen finden Sie in den offiziellen ASP.NET Core-Dokumenten

8

Diejenigen, die sich in einer gehosteten Umgebung mit sehr eingeschränkten Zugriffsrechten befinden, können stattdessen PersistKeysToFileSystem verwenden. Das Hinzufügen der folgenden Auflistung zu Startup.cs wird Ihr Problem beheben:

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

Sie können die Pfadzeichenfolge gemäß Ihren Anforderungen ändern. Überprüfen Sie auch ProtectKeysWith , wenn Sie das System so konfigurieren möchten, dass ruhende Schlüssel durch Aufrufen einer der ProtectKeysWith * -Konfigurations-APIs geschützt werden.

1
vahid

Werfen Sie einen Blick auf dies aus dem DataProtection Git-Repository

Kurz gesagt, es gibt einen Fehler in IIS, der möglicherweise niemals korrigiert wird und die korrekte Registrierung der DataProtection-Schlüssel verhindert. Es gibt ein Powershell-Skript , um die Registrierung manuell richtig einzurichten, damit sie für AspNet Core funktioniert. Nachdem Sie das Skript für jeden Anwendungspool ausgeführt haben, den Sie für AspNet Core-Anwendungen verwenden, funktionieren diese Anwendungen dann wie beabsichtigt.

0
Yepeekai