Auf dieser Seite

 Modulübersicht
 Zielsetzung
 Betrifft
 Verwendung dieses Moduls
 ASP.NET-Sicherheitsarchitektur
 Authentifizierungs- und Autorisierungsstrategien
 Konfigurieren der Sicherheit
 Programmieren der Sicherheit
 Windows-Authentifizierung
 Formularauthentifizierung
 Passport-Authentifizierung
 Benutzerdefinierte Authentifizierung
 Prozessidentität für ASP.NET
 Identitätswechsel
 Zugreifen auf Systemressourcen
 Zugreifen auf COM-Objekte
 Zugreifen auf Netzwerkressourcen
 Sichere Kommunikation
 Speichern von vertraulichen Daten
 Sichern von Sitzungs- und Ansichtsstatus
 Überlegungen zur Webfarm
 Zusammenfassung

Modulübersicht

ASP.NET ist für die Entwicklung der in diesem Handbuch besprochenen verteilten Webanwendungen von entscheidender Bedeutung. Es stellt eine Reihe umfangreicher und leicht zugänglicher Sicherheitsfunktionen bereit, die das Erstellen sicherer Webanwendungen vereinfachen. ASP.NET ist flexibel und erweiterbar und arbeitet in Verbindung mit vorhandenen Sicherheitsfunktionen von Internetinformationsdiensten (IIS), Windows-Plattform und .NET Framework. Dadurch können Sie angepasste Sicherheitsmechanismen entwickeln, die sich nahtlos in Ihre Anwendungen integrieren lassen.

Dieses Modul enthält hilfreiche Anleitungen und Empfehlungen zu den Themen Authentifizierung, Autorisierung und sichere Kommunikation beim Erstellen sicherer ASP.NET-Webanwendungen.

Hinweis: Viele Anleitungen und Empfehlungen dieses Moduls gelten auch für die Entwicklung von ASP.NET-Webdiensten und .NET Remoting-Objekten, die von ASP.NET verwaltet werden (eine Beschreibung folgt jeweils in den Modulen 10 und 11).

Zielsetzung

Themenbereiche:

• Sichern der ASP.NET-Anwendung

• Sichern von vertraulichen Daten und Statusinformationen, die von ASP.NET-Anwendungen verwaltet werden

• Einführung in die Sicherheitsarchitektur von ASP.NET-Anwendungen und Erläuterung, wie die Sicherheitsfunktionen von IIS, Windows, .NET Framework und ASP.NET zusammenarbeiten, damit Ihre Webanwendungen sicher gestaltet werden

• Auswahl einer für Ihre Anwendung geeigneten Authentifizierungs- und Autorisierungsstrategie

• Einführung in die Auswirkungen der ASP.NET-Prozessidentität und des Identitätswechsels auf die Fähigkeit Ihrer Anwendung, auf nachgeordnete Ressourcen wie Dateien und Datenbanken zuzugreifen

• Implementieren des Sicherheitsentwurfs für Ihre ASP.NET-Webanwendung mithilfe einer Kombination aus Produktkonfigurationstools und Programmiertechniken

Betrifft

Die Informationen in diesem Modul gelten für folgende Produkte und Technologien:

• Windows XP oder Windows 2000 Server (mit Service Pack 3) und höhere Betriebssysteme

• Microsoft Internetinformationsdienste (IIS) 5.0 und höher

• Microsoft Active Directory

• .NET Framework Version 1.0 (mit Service Pack 2)

• Microsoft Visual Studio® 1.0 .NET und höhere Versionen

• Visual C# .NET

• SQL Server 2000 (mit Service Pack 2) und höhere Versionen

Verwendung dieses Moduls

Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

• Sie müssen über Erfahrung in der Programmierung mit Visual C# .NET und Visual Studio .NET verfügen.

• Sie sollten über Erfahrung in der Entwicklung und Konfiguration von ASP.NET-Webanwendungen verfügen.

• Sie sollten Erfahrung in der Konfiguration der IIS-Sicherheit besitzen.

• Sie sollten über Erfahrung in der Konfiguration der Windows-Sicherheit und dem Erstellen von Benutzerkonten mithilfe der Windows-Verwaltungstools verfügen.

• Sie müssen Erfahrung in der Konfiguration von Active Directory besitzen.

• Sie müssen über Erfahrung bei der Entwicklung und Konfiguration von Enterprise Services-(COM+-)Anwendungen verfügen.

• Lesen Sie Modul 1, "Einführung". Hier wird die Bedeutung von Authentifizierung, Autorisierung und sicherer Kommunikation für verteilte Webanwendungen erläutert.

• Lesen Sie Modul 2, "Sicherheitsmodell für ASP.NET-Anwendungen". Hier finden Sie eine Übersicht der Architektur und Technologien, die bei der Erstellung verteilter ASP.NET-Webanwendungen zum Einsatz kommen. Außerdem wird hervorgehoben, wo Aspekte der Authentifizierung, Autorisierung und sicheren Kommunikation in diese Architektur integriert werden können.

• Lesen Sie Modul 3, "Authentifizierung und Autorisierung". Es enthält eine Einführung in die Authentifizierungs- und Autorisierungsmechanismen, die Ihnen bei der Verwendung von ASP.NET zur Verfügung stehen.

• Lesen Sie Modul 4, "Sichere Kommunikation". Es stellt eine Vielzahl von Technologien vor, mit denen Sie die Kommunikation zwischen ASP.NET und anderen Elementen einer verteilten Webanwendung sichern können.

• Lesen Sie die nachfolgend angegebenen Module. Sie finden hier schrittweise Anleitungen zur Implementierung vieler in diesem Modul behandelten Techniken:

  • "Vorgehensweise: Erstellen eines benutzerdefinierten Kontos zum Ausführen von ASP.NET"

  • "Vorgehensweise: Einrichten von SSL auf einem Webserver"

  • "Vorgehensweise: Verwenden von SSL zum Sichern der Kommunikation mit SQL Server 2000"

  • "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern"

  • "Vorgehensweise: Implementieren von IPrincipal"

  • "Vorgehensweise: Verwenden der Formularauthentifizierung mit SQL Server 2000"

  • "Vorgehensweise: Verwenden der Formularauthentifizierung mit Active Directory"

  • "Vorgehensweise: Erstellen von GenericPrincipal-Objekten bei der Formularauthentifizierung"

  • "Vorgehensweise: Implementieren der Kerberos-Delegierung unter Windows 2000"

ASP.NET-Sicherheitsarchitektur

Da ASP.NET mit IIS, .NET Framework sowie den vom Betriebssystem bereitgestellten Sicherheitsdiensten zusammenarbeitet, bietet es eine Reihe von Authentifizierungs- und Autorisierungsmechanismen. Diese Mechanismen sind in Abbildung 8.1 zusammengefasst.

Abbildung 8.1
ASP.NET-Sicherheitsdienste

In Abbildung 8.1 werden die Authentifizierungs- und Autorisierungsmechanismen veranschaulicht, die IIS und ASP.NET bereitstellen. Wenn ein Client eine Webanfrage startet, treten die folgenden Authentifizierungs- und Autorisierungsereignisse ein:

1. Die HTTP(S)-Webanfrage wird vom Netzwerk empfangen. Sie können SSL verwenden, um die Serveridentität (mithilfe von Serverzertifikaten) und wahlweise die Clientidentität sicherzustellen.

   Hinweis: SSL bietet auch einen sicheren Kanal, um vertrauliche Daten zu schützen, die zwischen Client und Server (und umgekehrt) übertragen werden.

2. IIS authentifiziert den Benutzer über die Standard-, Digest-, integrierte (NTLM oder Kerberos) oder Zertifikatsauthentifizierung. Wenn die gesamte oder ein Teil der Site keinen authentifizierten Zugriff erfordert, kann IIS für die anonyme Authentifizierung konfiguriert werden. IIS erstellt für jeden authentifizierten Benutzer ein Windows-Zugriffstoken. Wenn die anonyme Authentifizierung gewählt wurde, erstellt IIS für das anonyme Internetbenutzerkonto (standardmäßig IUSR_MACHINE) ein Zugriffstoken.

3. IIS autorisiert den Benutzer für den Zugriff auf die angeforderte Ressource. Um den Zugriff zu autorisieren, werden durch Access Control Lists (ACLs oder Zugriffssteuerungslisten) definierte NTFS-Berechtigungen verwendet, die der angeforderten Ressource zugeordnet sind. IIS kann auch so konfiguriert werden, dass nur Anforderungen von Clientcomputern mit bestimmten IP-Adressen akzeptiert werden.

4. IIS übergibt das authentifizierte Windows-Zugriffstoken des Benutzers an ASP.NET (hierbei kann es sich um das Zugriffstoken des anonymen Internetbenutzers handeln, wenn die anonyme Authentifizierung verwendet wird).

5. Der Benutzer wird von ASP.NET authentifiziert.
   Wenn ASP.NET für die Windows-Authentifizierung konfiguriert ist, erfolgt an dieser Stelle keine weitere Authentifizierung. ASP.NET akzeptiert dann jedes von IIS erhaltene Token.

   Wenn ASP.NET für die Formularauthentifizierung konfiguriert ist, werden die vom Benutzer bereitgestellten Anmeldeinformationen (mithilfe eines HTML-Formulars) anhand eines Datenspeichers authentifiziert, bei dem es sich in der Regel um eine Microsoft® SQL Server-Datenbank oder einen Active Directory®-Verzeichnisdienst handelt. Wenn ASP.NET für die Passport-Authentifizierung konfiguriert ist, wird der Benutzer an eine Passport-Website weitergeleitet, wo er durch einen Passport-Authentifizierungsdienst authentifiziert wird.

6. ASP.NET authentifiziert den Zugriff auf die angeforderte Ressource oder Operation.
   UrlAuthorizationModule (ein vom System bereitgestelltes HTTP-Modul) verwendet in der Datei web.config konfigurierte Autorisierungsregeln (insbesondere das <authorization>-Element), um sicherzustellen, dass der Benutzer auf die angeforderte Datei oder den Ordner zugreifen kann.

   Bei der Windows-Authentifizierung prüft FileAuthorizationModule (ein weiteres HTTP-Modul), ob der Benutzer über die erforderlichen Berechtigungen verfügt, um auf die angeforderte Ressource zugreifen zu können. Das Zugriffstoken des Benutzers wird mit der ACL verglichen, die diese Ressource schützt.

   Sie können .NET-Rollen verwenden (entweder deklarativ oder programmatisch), um sicherzustellen, dass der Benutzer für den Zugriff auf die angeforderte Ressource oder die Durchführung der angeforderten Operation autorisiert ist.

7. Der Code in der Anwendung greift mithilfe einer bestimmten Identität auf lokale und/oder Remoteressourcen zu. ASP.NET führt standardmäßig keinen Identitätswechsel durch, weshalb das konfigurierte ASP.NET-Prozesskonto die Identität bereitstellt. Alternative Optionen umfassen die Identität des ursprünglichen Benutzers (falls der Identitätswechsel aktiviert ist) oder eine konfigurierte Dienstidentität.

Gatekeeper

Die Autorisierungspunkte (oder Gatekeeper) in einer ASP.NET-Webanwendung werden von IIS und ASP.NET bereitgestellt:

IIS

Bei deaktivierter anonymer Authentifizierung gestattet IIS nur Anforderungen von Benutzern, die entweder in einer eigenen oder in einer vertrauenswürdigen Domäne authentifiziert werden können.

Bei statischen Dateitypen (z. B. JPG, GIF- und HTM-Dateien, d. h. Dateien, die nicht einer ISAPI-Erweiterung zugeordnet sind) verwendet IIS die NTFS-Berechtigungen zur Zugriffssteuerung, die der angeforderten Datei zugeordnet sind.

ASP.NET

Zu den ASP.NET-Gatekeepern gehören UrlAuthorizationModule, FileAuthorizationModule sowie Hauptberechtigungen und Rollenüberprüfungen.

UrlAuthorizationModule

Sie können <authorization>-Elemente in der Datei web.config konfigurieren, um zu steuern, welche Benutzer und Benutzergruppen Zugriff auf die Anwendung erhalten sollen. Die Autorisierung basiert auf dem IPrincipal-Objekt, das in HttpContext.User gespeichert ist.

FileAuthorizationModule

Für Dateitypen, die von IIS der ASP.NET ISAPI-Erweiterung (Aspnet_isapi.dll) zugeordnet sind, werden anhand des authentifizierten Windows-Zugriffstokens des Benutzers (z. B. IUSR_MACHINE) automatische Zugriffsüberprüfungen mit der ACL durchgeführt, die der angeforderten ASP.NET-Datei zugeordnet ist.

Hinweis: Der Identitätswechsel ist für eine funktionierende Dateiautorisierung nicht erforderlich.

Die FileAuthorizationModule-Klasse führt Zugriffsüberprüfungen nur für die angeforderte Datei und nicht für Dateien durch, auf die der Code in der angeforderten Seite zugreift, obwohl für diese eine Zugriffsüberprüfung durch IIS erfolgt.

Wenn Sie z. B. die Datei Default.aspx anfordern und diese ein eingebettetes Benutzersteuerelement (Usercontrol.ascx) enthält, das wiederum ein Bildtag (Verweis auf Image.gif) einbezieht, führt FileAuthorizationModule eine Zugriffsüberprüfung für Default.aspx und Usercontrol.ascx durch, da IIS diese Dateitypen der ASP.NET ISAPI-Erweiterung zuordnet.

FileAuthorizationModule führt keine Überprüfung für Image.gif durch, da es sich hierbei um eine statische Datei handelt, die IIS intern behandelt. Da jedoch Zugriffsüberprüfungen für statische Dateien von IIS durchgeführt werden, ist dem authentifizierten Benutzer weiterhin mit einer ordnungsgemäß konfigurierten ACL die Leseberechtigung für die Datei zu erteilen.

Dieses Szenario ist in Abbildung 8.2 dargestellt.

Hinweis für Systemadministratoren: Der authentifizierte Benutzer muss für alle im Szenario einbezogenen Dateien die NTFS-Leseberechtigung besitzen. Die einzige Variable stellt der Gatekeeper dar, der zum Durchsetzen der Zugriffssteuerung gewählt wird. Das ASP.NET-Prozesskonto erfordert lediglich den Lesezugriff auf die in ASP.NET registrierten Dateitypen.

Abbildung 8.2
Zusammenarbeit der IIS und ASP.NET-Gatekeeper

In diesem Szenario können Sie den Zugriff am Dateigate verhindern. Wenn Sie die der Datei Default.aspx zugeordnete ACL konfigurieren und den Zugriff für einen bestimmten Benutzer verweigern, werden weder das Benutzersteuerelement noch eingebettete Bilder über den Code in Default.aspx an den Client gesendet.

Hauptberechtigungen und explizite Rollenüberprüfungen

Zusätzlich zu den konfigurierbaren IIS- und ASP.NET-Gatekeepern können Sie auch Hauptberechtigungen (deklarativ oder programmatisch) als zusätzlichen feinstufigen Zugriffssteuerungsmechanismus verwenden. Hauptberechtigungsüberprüfungen (von der PrincipalPermissionAttribute-Klasse durchgeführt) ermöglichen es, basierend auf der Identität und Gruppenmitgliedschaft einzelner Benutzer den Zugriff auf Klassen, Methoden oder einzelne Codeblöcke gemäß der Definition des IPrincipal-Objekts zu steuern, das dem aktuellen Thread zugeordnet ist.

Hinweis: Die zum Anfordern der Rollenmitgliedschaft verwendeten PrincipalPermission-Befehle unterscheiden sich vom Aufrufen von IPrincipal.IsInRole zum Testen der Rollenmitgliedschaft. Ersteres führt zu einer Ausnahmebedingung, wenn der Benutzer kein Mitglied der angegebenen Rolle ist, während im letzteren Fall einfach ein Boole'scher Wert zurückgegeben wird, um die Rollenmitgliedschaft zu bestätigen.

Bei der Windows-Authentifizierung hängt ASP.NET automatisch das WindowsPrincipal-Objekt an, das den authentifizierten Benutzer für die aktuelle Webanforderung (unter Verwendung von HttpContext.User) darstellt. Bei der Formular- und der Passport-Authentifizierung wird ein GenericPrincipal-Objekt mit der entsprechenden Identität und ohne Rollen erstellt und HttpContext.User zugeordnet.

Weitere Informationen

• Weitere Informationen zum Konfigurieren der Sicherheit erhalten Sie im Abschnitt "Konfigurieren der Sicherheit" weiter unten in diesem Modul.

• Weitere Informationen zum Programmieren der Sicherheit (und zu IPrincipal-Objekten) erhalten Sie im Abschnitt "Programmieren der Sicherheit" weiter unten in diesem Modul.

Authentifizierungs- und Autorisierungsstrategien

ASP.NET bietet eine Reihe von deklarativen und programmatischen Autorisierungsmechanismen, die zusammen mit einer Vielzahl von Authentifizierungsschemata verwendet werden können. Dadurch können Sie eine ausführliche Autorisierungsstrategie entwickeln sowie eine Strategie, die zum Bereitstellen verschiedener Feinstufigkeitsgrade konfiguriert werden kann, z. B. auf Benutzer- oder Benutzergruppenbasis (rollenbasiert).

In diesem Abschnitt wird erläutert, welche Autorisierungsoptionen (sowohl konfigurierbar als auch programmatisch) für eine Reihe häufig verwendeter Authentifizierungsoptionen zur Verfügung stehen.

Die im Folgenden beschriebenen Optionen werden hier kurz zusammengefasst:

• Windows-Authentifizierung mit Identitätswechsel

• Windows-Authentifizierung ohne Identitätswechsel

• Windows-Authentifizierung mit fester Identität

• Formularauthentifizierung

• Passport-Authentifizierung

Verfügbare Autorisierungsoptionen

In der folgenden Tabelle werden die verfügbaren Autorisierungsoptionen aufgeführt. Sie zeigt für jede Option an, ob Windows-Authentifizierung und/oder Identitätswechsel erforderlich sind. Wenn die Windows-Authentifizierung nicht erforderlich ist, steht die zugehörige Autorisierungsoption für alle anderen Authentifizierungstypen zur Verfügung. Verwenden Sie die Tabelle, um Ihre Authentifizierungs-/Autorisierungsstrategie zu optimieren.

Tabelle 8.1: Windows-Authentifizierung mit Identitätswechsel

Autorisierungsoption	Erfordert Windows-Authentifizierung	Erfordert Identitätswechsel
FileAuthorizationModule	Ja	Nein
UrlAuthorizationModule	Nein	Nein
PrincipalPermission-Befehle	Nein	Nein
.NET-Rollen	Nein	Nein
Enterprise Services-Rollen	Ja	Ja (innerhalb der ASP.NET-Webanwendung)
NTFS-Berechtigungen (für direkt angeforderte statische Dateitypen; ohne Zuordnung zu einer ISAPI-Erweiterung)	N/V – Diese Dateien werden nicht von ASP.NET bearbeitet. Mit jedem (nicht anonymen) IIS-Authentifizierungsmechanismus sollten Berechtigungen für einzeln authentifizierte Benutzer konfiguriert werden. Bei der anonymen Authentifizierung sollten Berechtigungen für IUSR_MACHINE konfiguriert werden.	Nein (IIS führt die Zugriffsüberprüfung durch)
NTFS-Berechtigungen (für Dateien, auf die Webanwendungscode zugreift)	Nein	Nein Beim Identitätswechsel konfigurieren Sie die ACLs für die gewechselte Windows-Identität, bei der es sich entweder um den ursprünglichen Benutzer oder um die Identität handelt, die im <identity>-Element in der Datei web.config angegeben ist.

Windows-Authentifizierung mit Identitätswechsel

Die folgenden Konfigurationselemente zeigen, wie die Windows-Authentifizierung (IIS) und der Identitätswechsel deklarativ in der Datei web.config oder machine.config aktiviert werden.

Hinweis: Konfigurieren Sie die Authentifizierung auf Anwendungsbasis jeweils in der Datei web.config.

<authentication mode="Windows" />
<identity impersonate="true" />

Bei dieser Konfiguration nimmt der ASP.NET-Anwendungscode die Identität des für IIS authentifizierten Benutzers an.

Konfigurierbare Sicherheit

Wenn Sie die Windows-Authentifizierung zusammen mit dem Identitätswechsel verwenden, stehen Ihnen die folgenden Autorisierungsoptionen zur Verfügung:

• Windows-ACLs

  • Vom Client angeforderte Ressourcen – Die FileAuthorizationModule-Klasse von ASP.NET führt Zugriffsüberprüfungen für angeforderte Dateitypen durch, die der ASP.NET ISAPI zugeordnet sind. Sie verwendet dazu das Zugriffstoken des ursprünglichen Benutzers sowie die ACL, die den angeforderten Ressourcen zugeordnet ist.
    Für statische Dateitypen (keiner ISAPI-Erweiterung zugeordnet) führt IIS Zugriffsüberprüfungen durch, wobei das Zugriffstoken des Benutzers sowie die der Datei zugeordnete ACL verwendet werden.

  • Ressourcen, auf die die Datei zugreift – Sie können Windows-ACLs von Ressourcen, auf die Ihre Anwendung zugreift (Dateien, Ordner, Registrierungsschlüssel, Active Directory-Objekte usw.), anhand des ursprünglichen Benutzers konfigurieren.

• URL-Autorisierung – Konfigurieren Sie die URL-Autorisierung in der Datei web.config. Bei der Windows-Authentifizierung weisen Benutzernamen die Form DomainName\UserName auf, während Rollen den Windows-Gruppen 1:1 zugeordnet werden.

  <authorization>
    <deny user="DomainName\UserName" />
    <allow roles="DomainName\WindowsGroup" />
  </authorization>
  

• Enterprise Services-(COM+-)Rollen – Rollen werden im COM+-Katalog verwaltet. Sie können Rollen mit dem Verwaltungsprogramm oder -skript für Komponentendienste verwenden.

Programmatische Sicherheit

Die programmatische Sicherheit bezieht sich auf Sicherheitsprüfungen, die sich im Webanwendungscode befinden. Die folgenden programmatischen Sicherheitsoptionen stehen Ihnen zur Verfügung, wenn Sie die Windows-Authentifizierung und den Identitätswechsel verwenden.

• PrincipalPermission-Befehle

  • Imperativ (inline im Code einer Methode enthalten)

        PrincipalPermission permCheck = new PrincipalPermission(
                                           null, @"DomainName\WindowsGroup");
        permCheck.Demand();
    

  • Deklarativ (Attribute, die Schnittstellen, Klassen und Methoden voranstellen)

    [PrincipalPermission(SecurityAction.Demand, 
                      Role=@"DomainName\WindowsGroup)]
    

• Explizite Rollenüberprüfungen – Sie können die Rollenüberprüfungen mithilfe der Schnittstelle IPrincipal durchführen.

  IPrincipal.IsInRole(@"DomainName\WindowsGroup");
  

• Enterprise Services-(COM+-)Rollen – Sie können die Rollenüberprüfungen mithilfe der IPrincipal-Klasse programmatisch durchführen.

  ContextUtil.IsCallerInRole("Manager")
  

Verwendungshinweise

Verwenden Sie die Windows-Authentifizierung und den Identitätswechsel, wenn Folgendes zutrifft:

• Die Benutzer Ihrer Anwendung verfügen über Windows-Konten, die vom Server authentifiziert werden können.

• Sie müssen den Sicherheitskontext des ursprünglichen Benutzers an die mittlere und/oder die Datenebene der Webanwendung weitergeben, um eine feinstufige Autorisierung (auf Benutzerbasis) zu unterstützen.

• Sie müssen den Sicherheitskontext des ursprünglichen Benutzers an die nachgeordneten Datenebenen weitergeben, um die Überwachung auf Betriebssystemebene zu unterstützen.

Bevor Sie den Identitätswechsel in Ihrer Anwendung verwenden, machen Sie sich mit den relativen Vor- und Nachteilen dieses Ansatzes im Vergleich zum Modell der vertrauenswürdigen Subsysteme vertraut. Diese Vor- und Nachteile werden in Modul 3, "Authentifizierung und Autorisierung", im Abschnitt "Autorisierungsansätze" unter "Auswählen eines Ressourcenzugriffsmodells" erläutert.

Folgendes zählt zu den Nachteilen des Identitätswechsels:

• Verringerte Skalierbarkeit von Anwendungen, da man Datenbankverbindungen nicht effektiv zusammenfassen kann.

• Erhöhter Verwaltungsaufwand, da ACLs für Back-End-Ressourcen für einzelne Benutzer konfiguriert werden müssen.

• Die Delegierung erfordert eine Kerberos-Authentifizierung und eine entsprechend konfigurierte Umgebung.

Weitere Informationen

• Weitere Informationen zur Windows-Authentifizierung finden Sie unter "Windows-Authentifizierung" weiter unten in diesem Modul.

• Weitere Informationen zum Identitätswechsel finden Sie unter "Identitätswechsel" weiter unten in diesem Modul.

• Weitere Informationen zur URL-Autorisierung erhalten Sie unter "Hinweise zur URL-Autorisierung" weiter unten in diesem Modul.

• Weitere Informationen zu Enterprise Services-(COM+-)Rollen finden Sie in Modul 9, "Enterprise Services-Sicherheit".

Windows-Authentifizierung ohne Identitätswechsel

Die folgenden Konfigurationselemente zeigen, wie die Windows-Authentifizierung (IIS) und der Identitätswechsel deklarativ in der Datei web.config aktiviert werden.

<authentication mode="Windows" />
<!-- Die nachfolgende Einstellung entspricht dem Zustand, in dem kein Identity-Element vorhanden ist -->
<identity impersonate="false" />

Konfigurierbare Sicherheit

Wenn Sie die Windows-Authentifizierung ohne Identitätswechsel verwenden, stehen Ihnen die folgenden Autorisierungsoptionen zur Verfügung:

• Windows-ACLs

  • Vom Client angeforderte Ressourcen – Die FileAuthorizationModule-Klasse von ASP.NET führt Zugriffsüberprüfungen für angeforderte Dateitypen durch, die der ASP.NET ISAPI zugeordnet sind. Sie verwendet dazu das Zugriffstoken des ursprünglichen Benutzers sowie die ACL, die den angeforderten Ressourcen zugeordnet ist. Der Identitätswechsel ist nicht erforderlich.
    Für statische Dateitypen (keiner ISAPI-Erweiterung zugeordnet) führt IIS Zugriffsüberprüfungen durch, wobei sie das Zugriffstoken des Benutzers sowie die der Datei zugeordnete ACL verwendet.

  • Ressourcen, auf die die Datei zugreift – Konfigurieren Sie Windows-ACLs von Ressourcen, auf die Ihre Anwendung zugreift (Dateien, Ordner, Registrierungsschlüssel, Active Directory-Objekte usw.), anhand der ASP.NET-Prozessidentität.

• URL-Autorisierung – Konfigurieren Sie die URL-Autorisierung in der Datei web.config. Bei der Windows-Authentifizierung weisen Benutzernamen die Form DomainName\UserName auf, während Rollen den Windows-Gruppen 1:1 zugeordnet werden.

  <authorization>
    <deny user="DomainName\UserName" />
    <allow roles="DomainName\WindowsGroup" />
  </authorization>
  

Programmatische Sicherheit

Die folgenden programmatischen Sicherheitsoptionen sind verfügbar:

• PrincipalPermission-Befehle

  • Imperativ

        PrincipalPermission permCheck = new PrincipalPermission(
                                             null, @"DomainName\WindowsGroup");
        permCheck.Demand();
    

  • Deklarativ

    [PrincipalPermission(SecurityAction.Demand, 
                      Role=@"DomainName\WindowsGroup")]
    

• Explizite Rollenüberprüfungen – Sie können die Rollenüberprüfungen mithilfe der Schnittstelle IPrincipal durchführen.

  IPrincipal.IsInRole(@"DomainName\WindowsGroup");
  

Verwendungshinweise

Verwenden Sie die Windows-Authentifizierung ohne Identitätswechsel, wenn Folgendes zutrifft:

• Die Benutzer Ihrer Anwendung verfügen über Windows-Konten, die vom Server authentifiziert werden können.

• Sie möchten eine feste Identität für den Zugriff auf nachgeordnete Ressourcen verwenden (z. B. Datenbanken), um das Verbindungspooling zu unterstützen.

Weitere Informationen

• Weitere Informationen zur Windows-Authentifizierung finden Sie unter "Windows-Authentifizierung" weiter unten in diesem Modul.

• Weitere Informationen zur URL-Autorisierung erhalten Sie unter "Hinweise zur URL-Autorisierung" weiter unten in diesem Modul.

Windows-Authentifizierung mit fester Identität

Das <identity>-Element in der Datei web.config unterstützt optionale Benutzernamen- und Kennwortattribute. Dadurch können Sie für Ihre Anwendung eine bestimmte feste Identität für den Identitätswechsel konfigurieren. Dies wird im folgenden Fragment der Konfigurationsdatei veranschaulicht.

<identity impersonate="true"
          userName="registry:HKLM\SOFTWARE\YourSecureApp\
                    identity\ASPNET_SETREG,userName"
          password="registry:HKLM\SOFTWARE\YourSecureApp\
                    identity\ASPNET_SETREG,password" />

Das Beispiel zeigt das <identity>-Element. Die Anmeldeinformationen sind in der Registrierung mithilfe des Dienstprogramms aspnet_setreg.exe verschlüsselt worden. Die Klartextwerte für die Attribute Benutzername und Kennwort wurden durch Zeiger ersetzt, die auf den gesicherten Registrierungsschlüssel und benannte Werte verweisen, die die verschlüsselten Anmeldeinformationen enthalten. Einzelheiten zu diesem Dienstprogramm und zum Download finden Sie im Artikel Q329290, "HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" (englischsprachig), in der Microsoft Knowledge Base.

Verwendungshinweise

Der Wechsel zu festen Identitäten wird nicht empfohlen, wenn das .NET Framework 1.0 auf Servern unter Windows 2000 verwendet wird. Denn in diesem Fall müssten Sie dem ASP.NET-Prozesskonto das weitreichende Recht Als Teil des Betriebssystems handeln erteilen. Dieses Recht wird vom ASP.NET-Prozess benötigt, da er anhand der von Ihnen angegebenen Anmeldeinformationen einen LogonUser-Aufruf ausführt.

Hinweis: Das .NET Framework Version 1.1 stellt für dieses Szenario unter Windows 2000 eine Erweiterung bereit. Die Anmeldung wird vom IIS-Prozess durchgeführt, damit ASP.NET das Recht Als Teil des Betriebssystems handeln nicht erfordert.

Formularauthentifizierung

Die folgenden Konfigurationselemente zeigen, wie die Formularauthentifizierung deklarativ in der Datei web.config aktiviert wird.

<authentication mode="Formulare">
  <forms loginUrl="logon.aspx" name="AuthCookie" timeout="60" path="/">
  </forms>
</authentication>

Konfigurierbare Sicherheit

Bei der Formularauthentifizierung stehen Ihnen die folgenden Autorisierungsoptionen zur Verfügung:

• Windows-ACLs

  • Vom Client angeforderte Ressourcen – Angeforderte Ressourcen erfordern ACLs, die den Lesezugriff auf das anonyme Internetbenutzerkonto zulassen. (IIS sollte so konfiguriert sein, dass bei der Formularauthentifizierung der anonyme Zugriff ermöglicht wird).
    Die ASP.NET-Dateiautorisierung steht nicht zur Verfügung, da sie die Windows-Authentifizierung erfordert.

  • Ressourcen, auf die die Datei zugreift – Konfigurieren Sie Windows-ACLs von Ressourcen, auf die Ihre Anwendung zugreift (Dateien, Ordner, Registrierungsschlüssel und Active Directory-Objekte), anhand der ASP.NET-Prozessidentität.

• URL-Autorisierung

  Konfigurieren Sie die URL-Autorisierung in der Datei web.config. Bei der Formularauthentifizierung wird das Format von Benutzernamen durch den benutzerdefinierten Datenspeicher bestimmt (eine SQL Server-Datenbank oder Active Directory).

  • Bei Verwendung eines SQL Server-Datenspeichers:

    <authorization>
    <deny users="?" />
      <allow users="Mary,Bob,Joe" roles="Manager,Verkauf" />
    </authorization>
    

  • Wenn Sie Active Directory als Datenspeicher verwenden, werden Benutzer- und Gruppennamen im X.500-Format angezeigt:

    <authorization>
      <deny users="someAccount@domain.corp.yourCompany.com" />
      <allow roles ="CN=Smith James,CN=FTE_northamerica,CN=Users,
                    DC=domain,DC=corp,DC=yourCompany,DC=com" />
    </authorization>
    

Programmatische Sicherheit

Die folgenden programmatischen Sicherheitsoptionen sind verfügbar:

• PrincipalPermission-Befehle

  • Imperativ

        PrincipalPermission permCheck = new PrincipalPermission(
                                             null, "Manager");
        permCheck.Demand();
    

  • Deklarativ

    [PrincipalPermission(SecurityAction.Demand, 
                      Role="Manager")]
    

• Explizite Rollenüberprüfungen – Sie können die Rollenüberprüfungen mithilfe der Schnittstelle IPrincipal durchführen.

  IPrincipal.IsInRole("Manager");
  

Verwendungshinweise

Die Formularauthentifizierung ist am besten für Internetanwendungen geeignet. Verwenden Sie die Formularauthentifizierung für folgende Situationen:

• Die Anwendungsbenutzer verfügen über keine Windows-Konten.

• Die Benutzer sollen sich durch Eingabe von Anmeldeinformationen über ein HTML-Formular anmelden.

Weitere Informationen

• Weitere Informationen zur Formularauthentifizierung finden Sie unter "Formularauthentifizierung " weiter unten in diesem Modul.

• Weitere Informationen zur URL-Autorisierung erhalten Sie unter "Hinweise zur URL-Autorisierung" weiter unten in diesem Modul.

Passport-Authentifizierung

Die folgenden Konfigurationselemente zeigen, wie die Passport-Authentifizierung deklarativ in der Datei web.config aktiviert wird.

<authentication mode="Passport" />

Verwendungshinweise

Die Passport-Authentifizierung wird im Internet verwendet, wenn Anwendungsbenutzer über keine Windows-Konten verfügen und Sie eine Lösung mit einer einzigen Anmeldung implementieren möchten. Benutzer, die sich zuvor bei einer teilnehmenden Passport-Site mit einem Passport-Konto angemeldet haben, müssen sich bei Ihrer Website nicht anmelden, wenn diese mit der Passport-Authentifizierung konfiguriert ist.

Konfigurieren der Sicherheit

In diesem Abschnitt werden die praktischen Schritte veranschaulicht, die zum Konfigurieren der Sicherheit für eine ASP.NET-Anwendung erforderlich sind. Diese Schritte sind in Abbildung 8.3 zusammengefasst.

Abbildung 8.3
Konfigurieren der ASP.NET-Anwendungssicherheit

Konfigurieren der IIS-Einstellungen

Zum Konfigurieren der IIS-Sicherheit müssen Sie die folgenden Schritte ausführen:

1. Installieren Sie optional ein Webserverzertifikat (wenn SSL erforderlich ist).

   Weitere Informationen finden Sie unter "Vorgehensweise: Einrichten von SSL auf einem Webserver" in diesem Handbuch.

2. Konfigurieren Sie die IIS-Authentifizierung.

3. Konfigurieren Sie optional die Clientzertifikatszuordnung (bei Verwendung der Zertifikatsauthentifizierung).

   Weitere Informationen zur Clientzertifikatszuordnung finden Sie im Artikel 313070, "SO WIRD'S GEMACHT: Client-Zertifikatszuordnungen in Internet Information Services (IIS) 5.0 konfigurieren", in der Microsoft Knowledge Base.

4. Legen Sie NTFS-Berechtigungen für Dateien und Ordner fest. IIS und die FileAuthorizationModule-Klasse von ASP.NET überprüfen, ob der authentifizierte Benutzer (oder das anonyme Internetbenutzerkonto) über die Rechte für den Zugriff auf die angeforderte Datei (basierend auf den Einstellungen für die ACLs) verfügt.

Konfigurieren der ASP.NET-Einstellungen

Die Einstellungen für die Konfiguration auf Anwendungsebene werden in den web.config-Dateien verwaltet, die sich im virtuellen Stammverzeichnis der Anwendung und optional in zusätzlichen Unterordnern befinden (diese Einstellungen können manchmal die Einstellungen für den übergeordneten Ordner außer Kraft setzen).

1. Konfigurieren der Authentifizierung – Dies sollte auf Anwendungsbasis in der Datei web.config festgelegt werden (nicht in der Datei machine.config), die sich im virtuellen Stammverzeichnis der Anwendung befindet.

   <authentication mode="Windows|Formulare|Passport|Keine" />
   

2. Konfigurieren des Identitätswechsels – Für ASP.NET-Anwendungen erfolgt standardmäßig kein Identitätswechsel. Die Anwendung wird mit der konfigurierten ASP.NET-Prozessidentität (in der Regel ASPNET) ausgeführt, und sämtliche Ressourcenzugriffe dieser Anwendung werden mit dieser Identität durchgeführt. Ein Identitätswechsel ist nur unter den folgenden Bedingungen erforderlich:

   • Sie verwenden Enterprise Services und möchten Enterprise Services-(COM+-)Rollen nutzen, um den Zugriff auf Funktionen zu autorisieren, die von Serviced Components bereitgestellt werden.

   • IIS wurde für die anonyme Authentifizierung konfiguriert, und Sie möchten das anonyme Internetkonto für Ressourcenzugriffe verwenden. Weitere Informationen zu diesem Ansatz finden Sie unter "Zugreifen auf Netzwerkressourcen" weiter unten in diesem Modul.

   • Sie müssen den Sicherheitskontext des authentifizierten Benutzers an die nächste Ebene weitergeben (z. B. die Datenbank).

   • Sie haben eine klassische ASP-Anwendung zu ASP.NET portiert und möchten beim Identitätswechsel dasselbe Verhalten erreichen. Das klassische ASP wechselt standardmäßig die Identität des Benutzers.

   Verwenden Sie das folgende <identity>-Element in der Datei web.config Ihrer Anwendung, um den ASP.NET-Identitätswechsel zu konfigurieren.

   <identity impersonate="true" />
   

3. Konfigurieren der Autorisierung – Die URL-Autorisierung legt fest, ob ein Benutzer oder eine Rolle bestimmte HTTP-Begriffe (z. B. GET, HEAD oder POST) für eine bestimmte Datei verwenden kann. Zum Implementieren der URL-Autorisierung führen Sie die folgenden Aufgaben aus.

   1. Sie fügen ein <authorization>-Element zu der Datei web.config hinzu, die sich im virtuellen Stammverzeichnis der Anwendung befindet.

   2. Sie schränken den Zugriff ein, indem Sie die Attribute allow und deny verwenden. Das folgende Beispiel für die Datei web.config verwendet die Windows-Authentifizierung und erteilt ausschließlich "Bob" und "Mary" den Zugriff.

      <authorization>
        <allow users="DomainName\Bob, DomainName\Mary" />
        <deny users="*" />
      </authorization>
      

      Wichtig: Sie müssen am Ende des <authorization>-Elements entweder <deny users="?"/> oder <deny users="*"/> hinzufügen, da sonst allen authentifizierten Identitäten der Zugriff gewährt wird.

Sichere Ressourcen

1. Verwenden Sie Windows-ACLs zum Sichern von Ressourcen, die Dateien, Ordner und Registrierungsschlüssel enthalten.
   Wenn Sie keinen Identitätswechsel durchführen, muss jede Ressource, auf die die Anwendung zugreift, eine ACL besitzen, die zumindest den Lesezugriff auf das ASP.NET-Prozesskonto erteilt.

   Wenn Sie einen Identitätswechsel vornehmen, müssen die Dateien und Registrierungsschlüssel über eine ACL verfügen, die zumindest den Lesezugriff für den authentifizierten Benutzer erteilt (oder für das anonyme Internetbenutzerkonto, wenn die anonyme Authentifizierung aktiv ist).

2. Sichern Sie die Dateien web.config und machine.config:

   • Verwenden Sie die richtigen ACLs – Wenn ASP.NET einen Identitätswechsel durchführt, erfordert die gewechselte Identität den Lesezugriff. Andernfalls erfordert die ASP.NET-Prozessidentität den Lesezugriff. Verwenden Sie das folgende Zugriffssteuerungselement für web.config und machine.config.

     System: Vollzugriff

     Administratoren: Vollzugriff

     Prozessidentität oder gewechselte Identität: Lesen

     Wenn Sie für das anonyme Internetbenutzerkonto (IUSR_MACHINE) keinen Identitätswechsel durchführen, sollten Sie den Zugriff auf dieses Konto verweigern.

     Hinweis: Wenn die Anwendung einer UNC-Freigabe zugeordnet ist, erfordert die UNC-Identität auch den Lesezugriff auf die Konfigurationsdateien.

   • Entfernen Sie unerwünschte HTTP-Module. Die Datei machine.config enthält eine Reihe von HTTP-Modulen (im <httpModules>-Element. Dabei handelt es sich um folgende Module:

     • WindowsAuthenticationModule

     • FormsAuthenticationModule

     • PassportAuthenticationModule

     • UrlAuthorizationModule

     • FileAuthorizationModule

     • OutputCacheModule

     • SessionStateModule

     Wenn die Anwendung ein bestimmtes Modul nicht verwendet, entfernen Sie es, um mögliche zukünftige Sicherheitsprobleme zu vermeiden, die mit einem bestimmten Modul verbunden sein können, wenn dieses in der Anwendung eingesetzt wird.

3. Optional können Sie die Konfigurationseinstellungen mithilfe des <location>-Elements und des Attributs allowOverride="false" sperren (wie im Folgenden beschrieben).

Sperren von Konfigurationseinstellungen

Konfigurationseinstellungen sind hierarchisch aufgebaut. Die Einstellungen der Datei web.config in Unterverzeichnissen setzen die Einstellungen der Datei web.config in übergeordneten Verzeichnissen außer Kraft. Die Einstellungen von web.config setzen außerdem die Einstellungen von machine.config außer Kraft.

Sie können Konfigurationseinstellungen sperren, um zu verhindern, dass diese in untergeordneten Ebenen blockiert werden, indem Sie das <location>-Element zusammen mit dem allowOverride-Attribut verwenden. Beispiel:

<location path="somepath" allowOverride="false" />
 . . . beliebige Konfigurationseinstellungen . . .
</location>

Beachten Sie, dass der Pfad auf eine Website oder ein virtuelles Verzeichnis verweisen kann und auf das benannte Verzeichnis sowie alle Unterverzeichnisse angewendet wird. Wenn Sie für allowOverride den Wert false festlegen, verhindern Sie, dass die im <location>-Element angegebenen Einstellungen von einer Konfigurationsdatei außer Kraft gesetzt werden, die sich in einem untergeordneten Verzeichnis befindet. Die Möglichkeit, die Konfigurationseinstellungen zu sperren, besteht für alle Arten von Einstellungen und nicht nur für Sicherheitseinstellungen wie Authentifizierungsmodi.

Im Kontext von machine.config muss ein vollständiger Pfad angegeben sein, der die Website, den Namen des virtuellen Verzeichnisses und optional ein Unterverzeichnis und einen Dateinamen enthält. Beispiel:

<location path="Web Site Name/VDirName/SubDirName/PageName.aspx" >
 . . .
</location>

Im Kontext von machine.config handelt es sich um einen relativen Pfad vom virtuellen Verzeichnis der Anwendung. Beispiel:

<location path="SubDirName/PageName.aspx" >
. . .
</location>

Verhindern von Dateidownloads

Sie können mithilfe der HttpForbiddenHandler-Klasse verhindern, dass bestimmte Dateitypen über das Internet heruntergeladen werden. Diese Klasse wird intern von ASP.NET verwendet, um den Download bestimmter Systemebenendateien zu verhindern (z. B. von Konfigurationsdateien, die web.config einschließen). Eine vollständige Liste der Dateitypen, die auf diese Weise eingeschränkt werden, finden Sie im Abschnitt <httpHandlers> der Datei machine.config.

Verwenden Sie den HttpForbiddenHandler für Dateien, die Ihre Anwendung intern nutzt und die nicht für den Download gedacht sind.

Hinweis: Sie müssen die Dateien auch mit Windows-ACLs sichern, um zu steuern, welche Benutzer auf die Dateien zugreifen können, wenn sie am Webserver angemeldet sind.

• So verwenden Sie "HttpForbiddenHandler", um den Download eines bestimmten Dateityps zu verhindern

  1. Erstellen Sie in IIS eine Anwendungszuordnung für den angegebenen Dateityp, um ihn der Datei Aspnet_isapi.dll zuzuordnen.

     1. Klicken Sie auf der Taskleiste auf Start, Programme, Verwaltung und wählen Sie dann Internetinformationsdienste.

     2. Wählen Sie das virtuelle Verzeichnis der Anwendung aus und klicken Sie mit der rechten Maustaste darauf. Klicken Sie dann auf Eigenschaften.

     3. Wählen Sie Anwendungseinstellungen und klicken Sie auf Konfiguration.

     4. Klicken Sie auf Hinzufügen, um eine neue Anwendungszuordnung zu erstellen.

     5. Klicken Sie auf Durchsuchen und wählen Sie dann
        c:\winnt\Microsoft.NET\Framework\v1.0.3705\aspnet_isapi.dll aus.

     6. Geben Sie die Dateierweiterung für den am Download zu hindernden Dateityp (z. B. .abc) in das Feld Erweiterung ein.

     7. Stellen Sie sicher, dass die Optionen Alle Verben und Skriptmodul aktiviert sind und die Option Prüfen, ob Datei existiert deaktiviert ist.

     8. Klicken Sie auf OK, um das Dialogfeld Hinzufügen/Bearbeiten der Zuordnung von Anwendungserweiterungen zu schließen.

     9. Klicken Sie auf OK, um das Dialogfeld Anwendungskonfiguration zu schließen, und dann erneut auf OK, um das Dialogfeld Eigenschaften zu schließen.

  2. Fügen Sie der Datei web.config für den angegebenen Dateityp die Zuordnung <HttpHandler> hinzu.

     Im Folgenden sehen Sie ein Beispiel für den Dateityp ABC.

     <httpHandlers>
       <add verb="*" path="*.abc" 
         type="System.Web.HttpForbiddenHandler"/>
     </httpHandlers>
     

Sichere Kommunikation

Verwenden Sie eine Kombination aus SSL und IPSec (Internet Protocol Security), um die Kommunikationsverbindungen zu sichern.

Weitere Informationen

• Weitere Informationen zur Verwendung von SSL zum Sichern der Verknüpfung zum Datenbankserver finden Sie unter "Vorgehensweise: Verwenden von SSL zum Sichern der Kommunikation mit SQL Server 2000".

• Weitere Informationen zur Verwendung von IPSec zwischen zwei Computern finden Sie unter "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern".

Programmieren der Sicherheit

Nachdem Sie die konfigurierbaren Sicherheitseinstellungen der Webanwendung eingerichtet haben, müssen Sie die Autorisierungsrichtlinie der Anwendung programmatisch erweitern und optimieren. Dazu gehören deklarative .NET-Attribute in den Assemblys und das Durchführen imperativer Autorisierungsüberprüfungen im Code.

In diesem Abschnitt werden die wesentlichen Programmierschritte veranschaulicht, die für die Autorisierung in einer ASP.NET-Webanwendung erforderlich sind.

Autorisierungsmuster

Im Folgenden wird die Standardvorgehensweise beim Autorisieren von Benutzern in der Webanwendung zusammengefasst:

1. Abrufen von Anmeldeinformationen

2. Überprüfen von Anmeldeinformationen

3. Zuweisen von Benutzern zu Rollen

4. Erstellen eines IPrincipal-Objekts

5. Einfügen des IPrincipal-Objekts in den aktuellen HTTP-Kontext

6. Autorisieren anhand der Benutzeridentität/Rollenmitgliedschaft

Wichtig: ASP.NET führt die Schritte 1 bis 5 automatisch durch, wenn Sie die Windows-Authentifizierung konfiguriert haben. Bei den anderen Authentifizierungsmechanismen (Formularauthentifizierung, Passport-Authentifizierung und benutzerdefinierte Ansätze) müssen Sie den Code für diese Schritte schreiben (wie unten beschrieben).

Abrufen von Anmeldeinformationen

Sie müssen zuerst eine Reihe von Anmeldeinformationen (Benutzername und Kennwort) vom Benutzer abrufen. Wenn die Anwendung keine Windows-Authentifizierung verwendet, müssen Sie sicherstellen, dass unverschlüsselte Anmeldeinformationen im Netzwerk ordnungsgemäß über SSL gesichert werden.

Überprüfen von Anmeldeinformationen

Wenn Sie die Windows-Authentifizierung konfiguriert haben, werden Anmeldeinformationen automatisch durch die zugrunde liegenden Dienste des Betriebssystems überprüft.

Wenn Sie einen alternativen Authentifizierungsmechanismus verwenden, müssen Sie den Code schreiben, um Anmeldeinformationen anhand eines Datenspeichers (z. B. SQL Server-Datenbank oder Active Directory) zu überprüfen.

Weitere Informationen zum sicheren Speichern von Benutzeranmeldeinformationen in einer SQL Server-Datenbank finden Sie unter "Authentifizieren von Benutzern anhand einer Datenbank" in Modul 12, "Datenzugriffssicherheit".

Zuweisen von Benutzern zu Rollen

Der Benutzerdatenspeicher sollte auch eine Liste der Rollen für jeden Benutzer enthalten. Sie müssen den Code zum Abrufen der Rollenliste für den überprüften Benutzer schreiben.

Erstellen eines IPrincipal-Objekts

Die Autorisierung erfolgt anhand des authentifizierten Benutzers, dessen Identitäts- und Rollenliste im IPrincipal-Objekt verwaltet wird (das sich im Kontext der aktuellen Webanforderung befindet).

Wenn Sie die Windows-Authentifizierung konfiguriert haben, erstellt ASP.NET automatisch ein WindowsPrincipal-Objekt. Es enthält die Identität des authentifizierten Benutzers zusammen mit einer Rollenliste, die der Liste der Windows-Gruppen entspricht, denen der Benutzer angehört.

Wenn Sie die Formular-, Passport- oder benutzerdefinierte Authentifizierung verwenden, müssen Sie in der Datei Global.asax im Ereignishandler Application_AuthenticateRequest Code hinzufügen, um das IPrincipal-Objekt zu erstellen. Die GenericPrincipal-Klasse wird von .NET Framework bereitgestellt und sollte in den meisten Szenarios verwendet werden.

Einfügen des IPrincipal-Objekts in den aktuellen HTTP-Kontext

Fügen Sie das IPrincipal-Objekt dem aktuellen HTTP-Kontext hinzu (mithilfe der Variablen HttpContext.User). ASP.NET führt dies automatisch durch, wenn Sie die Windows-Authentifizierung verwenden. Andernfalls müssen Sie das Objekt manuell hinzufügen.

Autorisieren anhand der Benutzeridentität und/oder Rollenmitgliedschaft

Verwenden Sie die .NET-Rollen entweder deklarativ (um die Autorisierung auf Klassen- oder Methodenebene zu erhalten) oder imperativ im Code, wenn die Anwendung eine feinstufige Autorisierungslogik erfordert.

Sie können deklarative oder imperative Hauptberechtigungen verwenden (mithilfe der PrincipalPermission-Klasse) oder explizite Rollenüberprüfungen durchführen, indem Sie die IPrincipal.IsInRole()-Methode aufrufen.

Das folgende Beispiel geht von einer Windows-Authentifizierung aus und veranschaulicht eine deklarative Hauptberechtigung. Die auf das Attribut folgende Methode wird nur ausgeführt, wenn der authentifizierte Benutzer ein Mitglied der Windows-Gruppe Manager ist. Wenn der Benutzer kein Mitglied dieser Gruppe ist, wird die Ausnahmebedingung SecurityException ausgelöst.

[PrincipalPermission(SecurityAction.Demand, 
                     Role=@"DomainName\Manager")]
public void SomeMethod()
{
}

Im folgenden Beispiel wird eine explizite Rollenüberprüfung innerhalb des Codes gezeigt. Dieses Beispiel geht von der Verwendung der Windows-Authentifizierung aus. Wird die Windows-Authentifizierung nicht verwendet, ist der Code dennoch sehr ähnlich. Anstatt für das User-Objekt eine Typumwandlung in ein WindowsPrincipal-Objekt durchzuführen, sollte es in ein GenericPrincipal-Objekt umgewandelt werden.

// Extrahieren Sie den authentifizierten Benutzer aus dem aktuellen HTTP-Kontext.
// Die User-Variable entspricht HttpContext.Current.
User, wenn Sie // eine ASPX- oder ASMX-Seite verwenden
WindowsPrincipal authenticatedUser = User as WindowsPrincipal;
if (null != authenticatedUser)
{
  // Hinweis: Verwenden Sie zum Abrufen des Benutzernamens des authentifizierten Benutzers
  // folgende Codezeile:
  // string username = authenticatedUser.Identity.Name;

  // Führen Sie eine Rollenüberprüfung durch
  if (authenticatedUser.IsInRole(@"DomainName\Manager") )
  {
    // Benutzer ist zur Durchführung von Managerfunktionen berechtigt
  }
}
else
{
  // Benutzer ist nicht zur Durchführung von Managerfunktionen berechtigt
}

Weitere Informationen

• Eine praktische Implementierung des obigen Musters für die Formularauthentifizierung finden Sie im Abschnitt "Formularauthentifizierung" weiter unten in diesem Modul.

Erstellen einer benutzerdefinierten IPrincipal-Klasse

Die von .NET Framework bereitgestellte GenericPrincipal-Klasse sollte in den meisten Fällen verwendet werden, wenn Sie einen anderen Mechanismus als die Windows-Authentifizierung verwenden. Diese Klasse ermöglicht Rollenüberprüfungen mithilfe der IPrincipal.IsInRole-Methode.

Gelegentlich müssen Sie eine eigene GenericPrincipal-Klasse erstellen. Zu den Gründen für die Implementierung einer eigenen IPrincipal-Klasse gehören die folgenden:

• Sie benötigen eine erweiterte Rollenüberprüfungsfunktionalität. Möglicherweise möchten Sie mit Methoden arbeiten, mit denen Sie prüfen können, ob ein bestimmter Benutzer mehreren Rollen angehört. Beispiel:

  CustomPrincipal.IsInAllRoles( "Rolle", "Rolle2", "Rolle3" )
  CustomPrincipal.IsInAnyRole( "Rolle1", "Rolle2", "Rolle3" )
  

• Sie möchten eine zusätzliche Methode oder Eigenschaft implementieren, die eine Liste der Rollen in Form eines Arrays zurückgibt. Beispiel:

  string[] roles = CustomPrincipal.Roles;
  

• Sie möchten, dass Ihre Anwendung eine Rollenhierarchielogik durchsetzt. Beispielsweise könnte ein "Senior Manager" als in der Hierarchie höher stehend als ein "Manager" betrachtet werden. Dies könnte mit Methoden wie den folgenden getestet werden.

  CustomPrincipal.IsInHigherRole("Manager");
  CustomPrincipal.IsInLowerRole("Manager");
  

• Sie möchten eine verzögerte Initialisierung der Rollenlisten implementieren. Beispielsweise könnten Sie die Rollenliste nur dann dynamisch laden, wenn eine Rollenüberprüfung angefordert wird.

• Sie möchten die Schnittstelle IIdentity implementieren, um den Benutzer durch ein X509ClientCertificate identifizieren zu lassen. Beispiel:

  CustomIdentity id = CustomPrincipal.Identity;
  X509ClientCertificate cert = id.ClientCertificate;
  

Weitere Informationen

Weitere Informationen zum Erstellen einer eigenen IPrincipal-Klasse finden Sie unter "Vorgehensweise: Implementieren von IPrincipal" in diesem Handbuch.

Windows-Authentifizierung

Verwenden Sie die Windows-Authentifizierung, wenn die Benutzer der Anwendung über Windows-Konten verfügen, die vom Server authentifiziert werden können (z. B. in Internetszenarios).

Wenn Sie ASP.NET für die Windows-Authentifizierung konfigurieren, führt IIS die Benutzerauthentifizierung mit dem konfigurierten IIS-Authentifizierungsmechanismus durch. Dies ist in Abbildung 8.4 dargestellt.

Abbildung 8.4
ASP.NET Windows-Authentifizierung verwendet IIS zum Authentifizieren von Benutzern

Das Zugriffstoken des authentifizierten Benutzers (bei dem es sich um das anonyme Internetbenutzerkonto handeln kann, wenn IIS für die anonyme Authentifizierung konfiguriert ist) wird für die ASP.NET-Anwendung zur Verfügung gestellt. Beachten Sie Folgendes:

• Das ermöglicht dem ASP.NET FileAuthorizationModule, Zugriffsüberprüfungen anhand der angeforderten ASP.NET-Dateien durchzuführen, die das Zugriffstoken des ursprünglichen Benutzers verwenden.

  Wichtig: Die ASP.NET-Dateiautorisierung führt nur Zugriffsüberprüfungen für Dateitypen durch, die der Datei Aspnet_isapi.dll zugeordnet sind.

• Die Dateiautorisierung erfordert keinen Identitätswechsel. Bei aktiviertem Identitätswechsel verwendet jeder von der Anwendung durchgeführte Ressourcenzugriff die Identität des Benutzers nach dem Identitätswechsel. Stellen Sie in diesem Fall sicher, dass die den Ressourcen zugeordneten ACLs einen Access Control Entry (ACE oder Zugriffssteuerungseintrag) enthalten, der zumindest den Lesezugriff für die Identität des ursprünglichen Benutzers erteilt.

Identifizieren des authentifizierten Benutzers

ASP.NET ordnet der aktuellen Webanforderung ein WindowsPrincipal-Objekt zu Dieses Objekt enthält die Identität des authentifizierten Windows-Benutzers zusammen mit einer Liste der Rollen, zu denen dieser Benutzer gehört. Bei diesen Objekten wird die Rollenliste automatisch aus der Reihe der Windows-Gruppen abgerufen, denen der Benutzer angehört.

Im folgenden Code wird veranschaulicht, wie die Identität des authentifizierten Windows-Benutzers abgerufen und ein einfacher Rollentest für die Autorisierung durchgeführt wird.

WindowsPrincipal user = User as WindowsPrincipal;
if (null != user)
{
  string username = user.Identity.Name;
  // Führen Sie eine Rollenüberprüfung durch
  if ( user.IsInRole(@"DomainName\Manager") )
  {
    // Benutzer ist zur Durchführung von Managerfunktionen berechtigt
  }
}
else
{
  // Sicherheitsausnahme auslösen, da kein WindowsPrincipal verfügbar ist
}  

Formularauthentifizierung

In Abbildung 8.5 wird die Reihenfolge der bei der Formularauthentifizierung von einem nicht authentifizierten Benutzer ausgelösten Ereignisse angezeigt, der versucht, auf eine gesicherte Datei oder Ressource zuzugreifen (wobei die URL-Autorisierung den Benutzerzugriff ablehnt).

Abbildung 8.5
Ereignisabfolge bei der Formularauthentifizierung

Im Folgenden wird die in Abbildung 8.5 dargestellte Ereignisabfolge beschrieben:

1. Der Benutzer startet eine Webanforderung für die Datei Default.aspx.

   IIS lässt die Anforderung zu, da der anonyme Zugriff aktiviert ist. ASP.NET überprüft die <authorization>-Elemente und findet ein <deny users=?" />-Element.

2. Der Benutzer wird wie im loginUrl-Attribut des <Formulare>-Element angegeben zur Anmeldeseite (Login.aspx) weitergeleitet.

3. Der Benutzer stellt die Anmeldeinformationen bereit und übermittelt das Anmeldeformular.

4. Die Anmeldeinformationen werden anhand eines Datenspeichers (SQL Server oder Active Directory) überprüft, Rollen werden optional abgerufen. Sie müssen eine Rollenliste abrufen, wenn Sie die rollenbasierte Autorisierung verwenden möchten.

5. Mit FormsAuthenticationTicket wird ein Cookie erstellt und an den Client zurückgesendet. Die Rollen werden optional im Ticket gespeichert. Durch das Speichern der Rollenliste im Ticket vermeiden Sie, dass Sie auf die Datenbank zugreifen müssen, um die Liste für folgende Webanforderungen desselben Benutzers erneut abzurufen.

6. Der Benutzer wird mithilfe der clientseitigen Umleitung zur ursprünglich angeforderten Seite (Default.aspx) umgeleitet.

7. Im Ereignishandler Application_AuthenticateRequest (in Global.asax) wird das Ticket zum Erstellen eines IPrincipal-Objekts verwendet und in HttpContext.User gespeichert.

   ASP.NET überprüft die <authorization> Elemente und findet ein <deny users=?" /> Element. Diesmal ist der Benutzer jedoch authentifiziert.

   ASP.NET überprüft die <authorization>-Elemente, um sicherzustellen, dass sich der Benutzer im <allow>-Element befindet.

   Dem Benutzer wird der Zugriff auf die Datei Default.aspx erteilt.

Entwicklungsschritte für die Formularauthentifizierung

In der folgenden Liste werden die wichtigsten Schritte hervorgehoben, die Sie zum Implementieren der Formularauthentifizierung durchführen müssen:

1. Konfigurieren von IIS für den anonymen Zugriff.

2. Konfigurieren von ASP.NET für die Formularauthentifizierung.

3. Erstellen eines Webanmeldeformulars und Überprüfen der bereitgestellten Anmeldeinformationen.

4. Abrufen einer Rollenliste aus dem benutzerdefinierten Datenspeicher.

5. Erstellen eines Tickets für die Formularauthentifizierung (Rollen im Ticket speichern).

6. Erstellen eines IPrincipal-Objekts.

7. Einfügen des IPrincipal-Objekts in den aktuellen HTTP-Kontext.

8. Autorisieren des Benutzers basierend auf dem Benutzernamen/der Rollenmitgliedschaft.

Konfigurieren von IIS für den anonymen Zugriff

Das virtuelle Verzeichnis der Anwendung muss in IIS für den anonymen Zugriff konfiguriert sein.

• So konfigurieren Sie IIS für den anonymen Zugriff

  1. Starten Sie das Verwaltungsprogramm Internetinformationsdienste.

  2. Wählen Sie das virtuelle Verzeichnis der Anwendung aus und klicken Sie mit der rechten Maustaste darauf. Klicken Sie dann auf Eigenschaften.

  3. Klicken Sie auf Verzeichnissicherheit.

  4. Klicken Sie in der Gruppe Steuerung des anonymen Zugriffs und der Authentifizierung auf Bearbeiten.

  5. Wählen Sie Anonymer Zugriff.

Konfigurieren von ASP.NET für die Formularauthentifizierung.

Im Folgenden wird eine Beispielkonfiguration aufgeführt.

<authentication mode="Formulare">
  <forms name="MyAppFormsAuth" 
       loginUrl="login.aspx" 
       protection="Verschlüsselung"
       timeout="20" 
       path="/" >
  </forms>
</authentication>

Erstellen eines Webanmeldeformulars und Überprüfen der bereitgestellten Anmeldeinformationen

Überprüfen Sie die Anmeldeinformationen anhand einer SQL Server-Datenbank oder mithilfe von Active Directory.

Weitere Informationen

• Weitere Informationen finden Sie unter Vorgehensweise: Verwenden der Formularauthentifizierung mit SQL Server 2000" in diesem Handbuch.

• Weitere Informationen finden Sie unter Vorgehensweise: Verwenden der Formularauthentifizierung mit Active Directory" in diesem Handbuch.

Abrufen einer Rollenliste aus dem benutzerdefinierten Datenspeicher

Rufen Sie Rollen aus einer Tabelle einer SQL Server-Datenbank oder in Active Directory konfigurierte Gruppen-/Verteilerlisten ab. Weitere Informationen finden Sie in den oben aufgeführten Ressourcen.

Erstellen eines Tickets für die Formularauthentifizierung

Speichern Sie die abgerufenen Rollen im Ticket. Dies wird im folgenden Code veranschaulicht.

// Dieser Ereignishandler wird ausgeführt, wenn der Benutzer auf die Anmeldeschaltfläche klickt,
// nachdem ein Satz Anmeldeinformationen angegeben wurde
private void Logon_Click(object sender, System.EventArgs e)
{
  // Überprüfen Sie die Anmeldeinformationen anhand einer SQL Server-Datenbank
  // oder Active Directory
  bool isAuthenticated = IsAuthenticated( txtUserName.Text, 
                                          txtPassword.Text );
  if (isAuthenticated == true )
  {
    // Rufen Sie die Rollenliste für diesen Benutzer aus der SQL Server-
    // Datenbank oder aus Active Directory ab. Die Rollen werden als
    // Zeichenfolge zurückgegeben, in der die Rollennamen durch einen senkrechten Balken (Pipe) 
    //voneinander getrennt sind, beispielsweise "Manager|Mitarbeiter|Verkauf|"
    // Auf diese Weise können Sie problemlos im Authentifizierungsticket gespeichert werden

    string roles = RetrieveRoles( txtUserName.Text, txtPassword.Text );

    // Erstellen Sie das Authentifizierungsticket, und speichern Sie die Rollen in der
    // benutzerdefinierten UserData-Eigenschaft des Authentifizierungstickets
    FormsAuthenticationTicket authTicket = new 
       FormsAuthenticationTicket(
                    1,                          // Version
                    txtUserName.Text,           // Benutzername
                    DateTime.Now,               // Erstellung
                    DateTime.Now.AddMinutes(20),// Ablauf
                    false,                      // Permanent
                    roles );                    // Benutzerdaten
     // Verschlüsseln Sie das Ticket.
     string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
     // Erstellen Sie ein Cookie, und fügen Sie das verschlüsselte Ticket dem 
     // Cookie in Form von Daten hinzu.
     HttpCookie authCookie = 
               new HttpCookie(FormsAuthentication.FormsCookieName,
                              encryptedTicket);

     // Fügen Sie das Cookie der Sammlung ausgehender Cookies hinzu. 
     Response.Cookies.Add(authCookie); 
     // Leiten Sie den Benutzer auf die ursprünglich angeforderte Seite um.
     Response.Redirect( FormsAuthentication.GetRedirectUrl(
                        txtUserName.Text, 
                        false ));
  }
}

Erstellen eines IPrincipal-Objekts

Erstellen Sie das IPrincipal-Objekt im Ereignishandler Application_AuthenticationRequest der Datei Global.asax. Verwenden Sie die GenericPrincipal-Klasse, wenn Sie die erweiterten rollenbasierten Funktionen nicht benötigen. Wenn doch, erstellen Sie eine benutzerdefinierte Klasse, die IPrincipal implementiert.

Einfügen des IPrincipal-Objekts in den aktuellen HTTP-Kontext

Im Folgenden wird das Erstellen des GenericPrincipal-Objekts veranschaulicht.

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
  // Extrahieren Sie das Formularauthentifizierungs-Cookie
  string cookieName = FormsAuthentication.FormsCookieName;
  HttpCookie authCookie = Context.Request.Cookies[cookieName];
  if(null == authCookie)
  {
    // Es ist kein Authentfizierungscookie vorhanden.
    return;
  } 
  FormsAuthenticationTicket authTicket = null;
  try
  {
    authTicket = FormsAuthentication.Decrypt(authCookie.Value);
  }
  catch(Exception ex)
  {
    // Protokollieren Sie Ausnahmedetails (aus Gründen der Überschaubarkeit ausgelassen)
    return;
  }
  if (null == authTicket)
  {
    // Cookie konnte nicht entschlüsselt werden.
    return; 
  }
  // Bei der Erstellung des Tickets wurde der UserData-Eigenschaft eine
  // durch einen senkrechten Balken (Pipe) getrennte Zeichenfolge der Rollennamen zugewiesen.
  string[] roles = authTicket.UserData.Split(new char[]{'|'});

  // Erstellen Sie ein Identitätsobjekt
  FormsIdentity id = new FormsIdentity( authTicket ); 
  // Dieser Prinzipal wird über die gesamte Anforderung hinweg übertragen.
  GenericPrincipal principal = new GenericPrincipal(id, roles);
  // Fügen Sie das neue Prinzipalobjekt an das aktuelle HttpContext-Objekt an
  Context.User = principal;
}

Autorisieren des Benutzers basierend auf dem Benutzernamen/der Rollenmitgliedschaft

Verwenden Sie deklarative Hauptberechtigungen, um den Zugriff auf Methoden einzuschränken. Verwenden Sie die imperativen Hauptberechtigungen und/oder expliziten Rollenüberprüfungen (IPrincipal.IsInRole), um innerhalb der Methoden eine feinstufige Autorisierung durchzuführen.

Richtlinien für die Formularimplementierung

• Verwenden Sie SSL beim Erfassen der Anmeldeinformationen mit einem HTML-Formular.
  Sie sollten SSL neben der Anmeldeseite auch für andere Seiten verwenden, wenn die Anmeldeinformationen oder das Authentifizierungscookie über das Netzwerk gesendet werden. Dadurch wird die Gefahr verringert, die mit Angriffen verbunden ist, bei denen Cookies wiedergegeben werden.

• Authentifizieren Sie Benutzer anhand eines benutzerdefinierten Datenspeichers. Verwenden Sie SQL Server oder Active Directory.

• Rufen Sie eine Rollenliste aus dem benutzerdefinierten Datenspeicher ab und speichern Sie eine Liste mit durch Trennzeichen getrennten Rollen in der UserData-Eigenschaft der FormsAuthenticationTicket-Klasse. Dadurch wird die Leistung verbessert, da nicht mehr für jede Webanforderung wiederholt auf den Datenspeicher zugegriffen werden muss. Außerdem müssen Sie die Anmeldeinformationen des Benutzers nicht im Authentifizierungscookie speichern.

• Wenn die Liste der Rollen sehr umfangreich ist und die Gefahr besteht, den Grenzwert für die Cookiegröße zu überschreiten, speichern Sie die Rollendetails im ASP.NET-Cacheobjekt oder der ASP.NET-Datenbank und rufen Sie diese dann für jede folgende Anforderung ab.

• Gehen Sie für jede Anforderung nach der ersten Authentifizierung wie folgt vor:

  • Rufen Sie die Rollen aus dem Ticket im Ereignishandler Application_AuthenticateRequest ab.

  • Erstellen Sie ein IPrincipal-Objekt und speichern Sie es im HTTP-Kontext (HttpContext.User). Es wird von .NET Framework ebenfalls zum aktuellen .NET-Thread (Thread.CurrentPrincipal) zugeordnet.

  • Verwenden Sie die GenericPrincipal-Klasse, außer es besteht ein bestimmter Grund dafür, eine IPrincipal-Implementierung zu erstellen (z. B. um erweiterte rollenbasierte Operationen zu unterstützen).

• Verwenden Sie zwei Cookies, eines für die Personalisierung und das andere für die sichere Authentifizierung und Autorisierung. Legen Sie das Personalisierungscookie als persistent fest (stellen Sie sicher, dass es keine Daten enthält, die eine Anforderung zum Durchführen einer eingeschränkten Operation zulassen, z. B. das Ablegen einer Anforderung im sicheren Teil einer Site).

• Verwenden Sie für jede Webanwendung einen separaten Cookienamen (mithilfe des Formulare-Attributs des <Formulare>-Elements) und Pfad. Dadurch wird sichergestellt, dass Benutzer, die für eine Anwendung authentifiziert sind, nicht auch als für andere Anwendungen authentifiziert eingestuft werden, die auf demselben Webserver verwaltet werden.

• Stellen Sie sicher, dass Cookies in den Clientbrowsern aktiviert sind. Informationen zu einem Ansatz, der die Formularauthentifizierung verwendet und keine Cookies erfordert, finden Sie unter "Formularauthentifizierung ohne Cookies" weiter unten in diesem Modul.

Weitere Informationen

• Weitere Informationen finden Sie unter Vorgehensweise: Verwenden der Formularauthentifizierung mit SQL Server 2000" in diesem Handbuch.

• Weitere Informationen finden Sie unter Vorgehensweise: Verwenden der Formularauthentifizierung mit Active Directory" in diesem Handbuch.

• Weitere Informationen finden Sie unter Vorgehensweise: Erstellen von GenericPrincipal-Objekten bei der Formularauthentifizierung" in diesem Handbuch.

Verwalten mehrerer Anwendungen mithilfe der Formularauthentifizierung

Wenn Sie mehrere Webanwendungen verwalten, die die Formularauthentifizierung auf demselben Webserver verwenden, ist es möglich, dass ein für eine Anwendung authentifizierter Benutzer eine Anforderung an eine andere Anwendung stellen kann, ohne zur Anmeldeseite dieser Anwendung umgeleitet zu werden. Die Regeln der URL-Autorisierung der zweiten Anwendung verweigern möglicherweise den Zugriff für den Benutzer, ohne ihm die Möglichkeit zu bieten, Anmeldeinformationen über das Anmeldeformular bereitzustellen.

Dies geschieht nur, wenn die Attribute für Name und Pfad im <Formulare>-Element für mehrere Anwendungen dieselben sind und alle Anwendung ein gemeinsames <machineKey>-Element in der Datei web.config verwenden.

Weitere Informationen

Weitere Informationen zu diesem Thema und zu Lösungsverfahren finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:

• Q313116, "PRB: Forms Authentication Requests Are Not Directed to loginUrl Page" (englischsprachig)

• Q310415, "PRB: Mobile Forms Authentication and Different Web Applications" (englischsprachig)

Formularauthentifizierung ohne Cookies

Wenn Sie eine Lösung für die Formularauthentifizierung suchen, die keine Cookies erfordert, sollten Sie den Ansatz in Erwägung ziehen, der von Microsoft Mobile Internet Toolkit verwendet wird. Die Authentifizierung über mobile Formulare baut auf der Formularauthentifizierung auf, verwendet jedoch die Abfragezeichenfolge, um anstatt eines Cookies das Authentifizierungsticket zu übermitteln.

Weitere Informationen

Weitere Informationen zur Authentifizierung über mobile Formulare finden Sie im Artikel Q311568, "HOWTO: How To Use Mobile Forms Authentication with Microsoft Mobile Internet Toolkit" (englischsprachig), in der Microsoft Knowledge Base.

Passport-Authentifizierung

Verwenden Sie die Passport-Authentifizierung, wenn die Benutzer Ihrer Anwendung über Passport-Konten verfügen und Sie eine Lösung mit einer einzigen Anmeldung für andere Sites implementieren möchten, die für Passport aktiviert sind.

Wenn Sie ASP.NET für die Passport-Authentifizierung konfigurieren, wird der Benutzer zum Anmelden aufgefordert und dann zur Passport-Site umgeleitet. Nach erfolgreicher Überprüfung der Anmeldeinformationen wird der Benutzer wieder zu Ihrer Website zurückgeleitet.

Konfigurieren von ASP.NET für die Passport-Authentifizierung

Verwenden Sie die folgenden Einstellungen für die Datei web.config, um ASP.NET für die Passport-Authentifizierung zu konfigurieren.

<authentication mode="Passport">
  <passport redirectUrl="intern" />
</authentication>
<authorization>
  <deny users="?" />
  <allow users="*" />
</authorization>

Zuordnen einer Passport-Identität zu Rollen in "Global.asax"

Implementieren Sie den Ereignishandler PassportAuthentication_OnAuthentication in der Datei Global.asax wie unten gezeigt, um eine Passport-Identität zu Rollen zuzuordnen.

void PassportAuthentication_OnAuthenticate(Object sender, 
                                           PassportAuthenticationEventArgs e)
{
  if(e.Identity.Name == "0000000000000001")
  {
    string[] roles = new String[]{"Entwickler", "Admin", "Tester"};
    Context.User = new GenericPrincipal(e.Identity, roles);
  }
}

Testen der Rollenmitgliedschaft

Das folgende Codefragment zeigt, wie die authentifizierte Passport-Identität abgerufen und die Rollenmitgliedschaft in einer ASPX-Seite überprüft wird.

PassportIdentity passportId = Context.User.Identity as PassportIdentity;
if (null == passportId)
{
  Response.Write("Keine PassportIdentity<br>");
  return;
}
Response.Write("IsInRole: Entwickler? " + Context.User.IsInRole("Entwickler"));

Benutzerdefinierte Authentifizierung

Wenn keines der im .NET Framework bereitgestellten Authentifizierungsmodule Ihren konkreten Authentifizierungsanforderungen entspricht, können Sie die benutzerdefinierte Authentifizierung verwenden und einen eigenen Authentifizierungsmechanismus implementieren. Ihr Unternehmen könnte z. B. schon über eine benutzerdefinierte Authentifizierungsstrategie verfügen, die von anderen Anwendungen ausgiebig genutzt wird.

So implementieren Sie die benutzerdefinierte Authentifizierung in ASP.NET:

• Konfigurieren Sie den Authentifizierungsmodus in der Datei web.config wie im Folgenden gezeigt. Dadurch wird ASP.NET darüber informiert, dass keine integrierten Authentifizierungsmodule aufgerufen werden sollen.

  <authentication mode="Keine" />
  

• Erstellen Sie eine Klasse, die die Schnittstelle System.Web.IHttpModule integriert, um ein benutzerdefiniertes HTTP-Modul zu erstellen. Dieses Modul sollte einen Hook im HttpApplication.AuthenticateRequest-Ereignis implementieren und einen Delegate bereitstellen, der bei jeder Anforderung für die Anwendung aufgerufen wird, wenn die Authentifizierung erforderlich ist.

  Folgende Kriterien müssen von einem Authentifizierungsmodul erfüllt werden:

  • Abrufen der Anmeldeinformationen vom Benutzer.

  • Überprüfen der Anmeldeinformationen anhand eines Speichers.

  • Erstellen eines IPrincipal-Objekts und Speichern in HttpContext.User.

  • Erstellen und Schützen eines Authentifizierungstokens und Rücksendung an den Benutzer (normalerweise in einer Abfragezeichenfolge, einem Cookie oder einem verborgenen Formularfeld).

  • Abrufen des Authentifizierungstokens bei nachfolgenden Anforderungen, anschließende Überprüfung und erneutes Ausstellen.

Weitere Informationen

Weitere Informationen zum Implementieren eines benutzerdefinierten HTTP-Moduls finden Sie im Artikel 307996, "SO WIRD'S GEMACHT: Erstellen eines ASP.NET-HTTP-Moduls mit Visual C# .NET", in der Microsoft Knowledge Base.