Identitätswechsel in ASP.NET
Aktualisiert: November 2007
Mithilfe des Identitätswechsels können ASP.NET-Anwendungen unter der Windows-Identität (Benutzerkonto) des Anwenders ausgeführt werden, der die Anforderung gestellt hat. Der Identitätswechsel wird für gewöhnlich bei Anwendungen verwendet, bei denen die Benutzerauthentifizierung über Microsoft Internetinformationsdienste (IIS) erfolgt.
In ASP.NET ist der Identitätswechsel standardmäßig deaktiviert. Wenn für eine bestimmte Anwendung der Identitätswechsel aktiviert ist, wird diese Anwendung im Kontext der Identität ausgeführt, deren Zugriffstoken von IIS an ASP.NET übergeben wird. Bei diesem Benutzertoken kann es sich um das Token eines authentifizierten Benutzers handeln (z. B. das Token eines angemeldeten Windows-Benutzers) oder um das Token, das IIS an anonyme Benutzer vergibt (i. d. R. die Identität IUSR_MACHINENAME).
Bei aktiviertem Identitätswechsel wird nur der Anwendungscode im Kontext des imitierten Benutzers ausgeführt. Das Kompilieren von Anwendungen und das Laden von Konfigurationsinformationen erfolgt mit der Identität des ASP.NET-Prozesses. Weitere Informationen finden Sie unter Konfigurieren der Prozessidentität in ASP.NET. Die kompilierte Anwendung wird im Verzeichnis Temporary ASP.NET Files abgelegt. Die von der Anwendung imitierte Identität muss über Lese- und Schreibzugriff auf dieses Verzeichnis verfügen. Ebenso muss die imitierte Identität mindestens über Lesezugriff auf die Dateien im Anwendungsverzeichnis und seinen Unterverzeichnissen verfügen. Weitere Informationen finden Sie unter Erforderliche Zugriffssteuerungslisten für ASP.NET.
.gif "Hinweis") Hinweis: |
|---|
Da ASP.NET beim Kompilieren von Anwendungen und Laden von Konfigurationsinformationen die Windows-Identität des ASP.NET-Prozesses verwendet, müssen Sie auf einem Server, der mehrere Anwendungen hostet, Anwendungscode und Konfigurationsinformationen der jeweiligen Anwendungen voneinander getrennt halten. Unter Windows Server 2003 können Sie mehrere Anwendungspools erstellen und für jeden Anwendungspool eine eindeutige Identität angeben. Anschließend können Sie den Zugriff auf die Anwendungsdateien mithilfe von Zugriffssteuerungslisten (ACLs) und mithilfe dieser Identitäten einschränken (wenn die Partition mit dem Dateisystem NTFS formatiert wurde). Angenommen, es liegen zwei Anwendungen App1 und App2 vor und die in beiden Anwendungen enthaltenen Informationen müssen gegeneinander abgesichert werden. Sie können App1 im Anwendungspool ApplicationPool1 ablegen, der über die Identität ID_ApplicationPool1 verfügt. App2 können Sie im Anwendungspool ApplicationPool2 ablegen, der die Identität ID_ApplicationPool2 verwendet. Das Konto ID_ApplicationPool1 erhält Zugriff auf die Dateien in App1, jedoch keinen Zugriff auf die Dateien in App2. ID_ApplicationPool2 erhält Zugriff auf die Dateien in App2, der Zugriff auf die Dateien in App1 wird jedoch verweigert. Beachten Sie, dass diese Unterscheidung unter Windows 2000 und Windows XP Professional nicht vorgenommen werden kann, da bei diesen Betriebssystemen für alle ASP.NET-Anwendungen eine einzige Prozessidentität verwendet wird. |
Der Identitätswechsel wird mit dem identity-Konfigurationselement gesteuert. Wie alle anderen Konfigurationsdirektiven ist auch diese Direktive hierarchisch gültig. Eine minimale Konfigurationsdatei zum Aktivieren des Identitätswechsels für eine Anwendung könnte wie folgt aussehen:
<configuration>
<system.web>
<identity impersonate="true"/>
</system.web>
</configuration>
Sie können auch Unterstützung für bestimmte Namen hinzufügen, um eine Anwendung unter einer konfigurierbaren Identität auszuführen, wie im folgenden Beispiel gezeigt:
<identity impersonate="true"
userName="contoso\Jane"
password="********" />
Ersetzen Sie den im vorherigen Beispiel aufgeführten Wert durch das richtige Kennwort.
| Hinweis: |
|---|
Im obigen Beispiel werden der Benutzername und das Kennwort im Klartext in der Konfigurationsdatei gespeichert. Es wird empfohlen, zur Erhöhung der Sicherheit der Anwendung den Zugriff auf die Datei Web.config mithilfe einer Zugriffssteuerungsliste (ACL) zu beschränken und das identity-Konfigurationselement in der Datei Web.config mithilfe der geschützten Konfiguration zu verschlüsseln. Weitere Informationen finden Sie unter Verschlüsseln von Konfigurationsinformationen mithilfe der geschützten Konfiguration. |
Die im Beispiel veranschaulichte Konfiguration bewirkt, dass die gesamte Anwendung unter der Identität contoso\Jane ausgeführt wird, unabhängig davon, unter welcher Identität die Anforderung gestellt wurde. Diese Art von Identitätswechsel kann an einen anderen Computer delegiert werden. Dies bedeutet, dass Sie unter Angabe des Namens und des Kennworts des imitierten Benutzers eine Verbindung zu einem anderen Computer im Netzwerk herstellen und auf Ressourcen wie Dateien oder auf SQL Server zugreifen können, wobei die integrierte Sicherheit verwendet wird. Wenn Sie den Identitätswechsel aktivieren und kein Domänenkonto als Identität angeben, können Sie nur dann eine Verbindung zu einem anderen Computer im Netzwerk herstellen, wenn die IIS-Anwendung für die Verwendung der Standardauthentifizierung konfiguriert ist.
| Hinweis: |
|---|
Unter Windows 2000 ist es nicht möglich, den Identitätswechsel unter Angabe der spezifischen Anmeldeinformationen der Identität des ASP.NET-Workerprozesses durchzuführen. Sie können jedoch den Identitätswechsel aktivieren, ohne die Anmeldeinformationen eines bestimmten Benutzers anzugeben. Die Anwendung nimmt dann die von IIS bestimmte Identität an. Weitere Informationen finden Sie im Artikel 810204, "PRB: Per Request Impersonation Does Not Work on Windows 2000 with ASP.NET," in der Microsoft Knowledge Base unter http://support.microsoft. |
Auslesen der imitierten Identität
Das folgende Codebeispiel zeigt, wie die Identität des imitierten Benutzers programmgesteuert ausgelesen wird:
Dim username As String = _
System.Security.Principal.WindowsIdentity.GetCurrent().Name
String username =
System.Security.Principal.WindowsIdentity.GetCurrent().Name;