Sichern von mit ASP.NET erstellten XML-Webdiensten

Dieses Thema bezieht sich auf eine veraltete Technologie. XML-Webdienste und XML-Webdienstclients sollten nun mithilfe der folgenden Technologie erstellt werden: Windows Communication Foundation.

Um entscheiden zu können, welche Sicherheitsimplementierung sich für einen Webdienst am besten eignet, müssen im Vorfeld zwei wichtige Sicherheitsprinzipien geprüft werden: die Authentifizierung und die Autorisierung. Die Authentifizierung besteht in dem Vorgang, eine Identität anhand von Anmeldeinformationen (wie Benutzername und Kennwort) über eine Authentifizierungsstelle zu validieren. Nachdem eine Identität authentifiziert wurde, wird durch die Autorisierung ermittelt, ob diese Identität autorisiert ist, auf eine Ressource zuzugreifen.

Für die mit ASP.NET erstellten Webdienste stehen als Sicherheitsoptionen die Authentifizierungs- und Autorisierungsoptionen zur Auswahl, die von ASP.NET oder einem benutzerdefinierten SOAP-basierten Sicherheitsmodell zur Verfügung gestellt werden. ASP.NET arbeitet mit den Internetinformationsdiensten (IIS) zusammen, um eine Reihe von Authentifizierungs- und Autorisierungsoptionen bereitzustellen. Es ist auch möglich, benutzerdefinierte Authentifizierungsoptionen zu erstellen, z. B. die Verwendung von SOAP-Headern. Darüber hinaus bietet ASP.NET die als Identitätswechsel bezeichnete Fähigkeit, eine Anforderung mit den Anmeldeinformationen des Clients auszuführen. Weitere Informationen zur Verwendung des Identitätswechsels finden Sie unter Identitätswechsel in ASP.NET.

In diesem Thema werden die Authentifizierungs- und Autorisierungsoptionen zusammengefasst, die für mit ASP.NET erstellten Webdiensten zur Verfügung stehen. Weitere Informationen zu den für ASP.NET-Webanwendungen verfügbaren Sicherheitsoptionen finden Sie unter Sichern von ASP.NET-Webanwendungen und Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication.

Weitere Informationen zum Zugreifen auf Remoteressourcen über ASP.NET-basierte Anwendungen finden Sie in den Themen "Das Modell mit Identitätswechsel/Delegierung" und "Das Modell mit vertrauenswürdigen Subsystemen" in Kapitel 3 von Building Secure ASP.NET Applications.

Authentifizierungsoptionen für XML-Webdienste

Da für mit ASP.NET erstellte Webdienste mehrere Optionen für das Authentifizieren von Clients verfügbar sind, stellt sich die Frage, welche Option für einen bestimmten Webdienst am besten geeignet ist. Bei der Wahl der richtigen Sicherheitsoption muss der Entwickler u. A. zwischen dem gewünschten Maß an Sicherheit und der Leistung abwägen. Bei einigen Webdiensten ist es wichtig, dass die Anmeldeinformationen der Clients verschlüsselt über das Netzwerk gesendet werden, sodass ein Algorithmus zur Verschlüsselung der Clientanmeldeinformationen unverzichtbar ist. Beispielsweise wird sich ein Entwickler, der einen Webdienst für Kreditkartentransaktionen schreibt, mehr Sorgen über den Diebstahl von Clientanmeldeinformationen als den Mehraufwand machen, der durch die Verschlüsselung der Kreditkarteninformationen entsteht.

In der folgenden Tabelle sind die Authentifizierungs- und Autorisierungsoptionen zusammengefasst, die für Webdienste zur Verfügung stehen, die mit ASP.NET erstellt wurden. Optionen mit dem Präfix "Windows" gehören zu den Microsoft Windows-Authentifizierungsoptionen, die für die mit ASP.NET erstellten Webdienste verfügbar sind.

Zusammenfassung der Authentifizierungsoptionen

Authentifizierungsoption	Beschreibung
Windows - Standardauthentifizierung	Wird für die nicht sichere Identifizierung von Clients verwendet. Hierbei werden Benutzername und Kennwort in base 64-codierten Zeichenfolgen als Klartext gesendet. Kennwörter und Benutzernamen werden bei diesem Authentifizierungstyp codiert, aber nicht verschlüsselt. So könnten Unbefugte, die über ein Tool zur Netzwerküberwachung verfügen, zielgerichtet Benutzernamen und Kennwörter abfangen.
Windows - Standardauthentifizierung über SSL	Wird für die sichere Identifizierung von Clients in Internetszenarios verwendet. Benutzername und Kennwort werden im Netzwerk als SSL-verschlüsselte Daten (Secure Sockets Layer) und nicht als Klartext gesendet. Diese Option ist relativ einfach zu konfigurieren und funktioniert in Internetszenarios. Der Einsatz von SSL beeinträchtigt jedoch die Leistung.
Windows - Digestauthentifizierung	Wird für die sichere Identifizierung von Clients in Internetszenarios verwendet. Die Clientanmeldeinformationen werden mit der Hashmethode verschlüsselt übertragen, sodass das Kennwort nicht als Klartext gesendet wird. Außerdem kann die Digestauthentifizierung auch über Proxyserver erfolgen. Dieser Typ wird jedoch von vielen anderen Plattformen nicht unterstützt.
Windows - Integrierte Windows-Authentifizierung	Verwendet NTLM oder Kerberos. Hier wird ein kryptografischer Austausch mit dem Microsoft Internet Explorer-Webbrowser des Benutzers verwendet.
Windows - Clientzertifikate	Wird für die sichere Identifizierung von Clients in Internet- und Intranetszenarios verwendet. Jeder Client benötigt ein Zertifikat von einer für beide Seiten vertrauenswürdigen Zertifizierungsstelle. Zertifikate werden optional den Benutzerkonten zugeordnet, die von IIS verwendet werden, um den Zugriff auf den Webdienst zu autorisieren.
Formulare	Wird von Webdiensten nicht unterstützt. Bei diesem System werden nicht authentifizierte Anforderungen unter Verwendung der clientseitigen http-Umleitung an ein HTML-Formular umgeleitet. Die meisten Clients von Webdiensten werden keine Anmeldeinformationen über eine Benutzeroberfläche bereitstellen wollen. Dieses Problem müssen Sie umgehen, wenn Sie die Formularauthentifizierung verwenden möchten.
SOAP-Header – Benutzerdefiniert	Hilfreiche Option für sichere und nicht sichere Internetszenarios. Benutzeranmeldeinformationen werden im SOAP-Header der SOAP-Nachricht übergeben. Der Webserver stellt unabhängig von der Plattform des Webdiensts eine benutzerdefinierte Authentifizierungsimplementierung bereit.

Bei allen oben aufgeführten Optionen, die Verwendung von SOAP-Headern ausgenommen, werden die Sicherheitseinstellungen durch eine Kombination aus Konfigurationsdateien und IIS festgelegt. Die benutzerdefinierte SOAP-Headeroption wird im Anschluss an den Autorisierungsabschnitt ausführlich behandelt, da diese Lösung sowohl die Authentifizierung als auch die Autorisierung beinhaltet.

Windows-Authentifizierung

Sowohl IIS als auch ASP.NET bieten durch die in Windows integrierte Sicherheit Unterstützung für die Authentifizierung von Webanwendungen, wozu auch Webdienste zählen. Windows stellt drei Optionen zur Authentifizierung bereit: Standardauthentifizierung, Digestauthentifizierung und integrierte Windows-Authentifizierung. Darüber hinaus kann jede dieser Optionen mit SSL verwendet werden. Da die Daten bei allen Windows-Authentifizierungsoptionen, mit Ausnahme der Standardauthentifizierung, verschlüsselt werden, wird die von SSL bereitgestellte zusätzliche Verschlüsselungsebene normalerweise nur in Verbindung mit der Standardauthentifizierung oder mit Clientzertifikaten verwendet.

Unabhängig von der verwendeten Windows-Authentifizierungsoption ähneln sich die Verfahren für das Einrichten des Webdiensts und des Webdienstclients. Weitere Informationen finden Sie unter Vorgehensweise: Konfigurieren eines XML-Webdiensts zur Windows-Authentifizierung. Es muss kein zusätzlicher Code zu einem Webdienst hinzugefügt werden, wenn dieser die Windows-Authentifizierung verwenden soll, da die Authentifizierungsoptionen in einer Konfigurationsdatei und in IIS festgelegt werden. Einem Webdienstclient muss Code hinzugefügt werden, mit dem die Clientanmeldeinformationen an den Webdienst übergeben werden.

Wenn SSL als Teil des von einem Webdienst verwendeten Authentifizierungsmechanismus ausgewählt wird, muss SSL über IIS für die Webanwendung, die den Webdienst enthält, oder für den Webdienst selbst konfiguriert werden. Aus der Dienstbeschreibung und folglich auch aus den von der Dienstbeschreibung generierten Proxyklassen geht hervor, dass der Webdienst SSL verwendet (sofern der Zugriff auf die Dienstbeschreibung und die Diensthilfeseite über SSL erfolgt). Die URL für den Webdienst wird innerhalb der Dienstbeschreibung "https" vorangestellt. Weitere Informationen zum Einrichten von SSL finden Sie in der IIS-Dokumentation.

Authentifizierung mit Clientzertifikaten

Clientzertifikate tragen zum Bereitstellen eines sicheren Authentifizierungsmechanismus bei, da Clients ein elektronisches Dokument, das so genannte Clientzertifikat, senden müssen, mit dem ein Client über eine SSL-Verbindung gegenüber dem Webserver identifiziert wird. Mit der SSL-Verbindung werden die im Clientzertifikat enthaltenen Clientanmeldeinformationen verschlüsselt über das Netzwerk übertragen. Die Kommunikation zwischen Client und Webserver wird verschlüsselt, indem die vom Client gesendeten Verschlüsselungsschlüssel mit den vom Webserver zur Verfügung gestellten Schlüsseln kombiniert werden. Nachdem die Verbindung eingerichtet wurde, können nur Client- und Servercomputer über diese SSL-Verbindung miteinander kommunizieren.

Ein Clientzertifikat kann von einer Zertifizierungsstelle angefordert werden, wobei es sich entweder um den Webserver selbst oder einen vertrauenswürdiger Vermittler zwischen Client und Server handeln kann. Nachdem ein Zertifikat bezogen und der Webserver für das Akzeptieren von Clientzertifikaten konfiguriert wurde, kann ein Client beim Aufruf eines Webdiensts das Clientzertifikat über eine SSL-Verbindung an den Webserver senden. Weitere Informationen zu Clientzertifikaten finden Sie in der IIS-Dokumentation. Weitere Informationen zum Einrichten der Authentifizierung mit Clientzertifikaten für einen Webdienst finden Sie unter Vorgehensweise: Konfigurieren eines XML-Webdiensts zur Windows-Authentifizierung.

Autorisierungsoptionen für XML-Webdienste

Die Autorisierung hat den Zweck zu bestimmen, ob einer Identität die angeforderte Art des Zugriffs auf eine gegebene Ressource gewährt werden soll. Es gibt zwei grundlegende Verfahren, den Zugriff auf eine gegebene Ressource zu autorisieren: Dateiautorisierung und URL-Autorisierung. Die Dateiautorisierung kann immer dann verwendet werden, wenn die Windows-Authentifizierung zum Einsatz kommt, da die Berechtigungen in IIS pro Datei vergeben werden. Die URL-Autorisierung kann mit einem beliebigen der von ASP.NET unterstützten integrierten Authentifizierungsmechanismen verwendet werden. Bei der URL-Autorisierung erfolgt die Konfiguration über eine Konfigurationsdatei. Dabei kann Benutzern der Zugriff auf die mit ASP.NET verknüpften Dateien, einschließlich ASMX-Dateien, selektiv gewährt oder verweigert werden.

Weitere Informationen zum Einrichten der Autorisierung pro Datei finden Sie in der IIS-Dokumentation.

Weitere Informationen zum Einrichten von Autorisierung mit einer Konfigurationsdatei finden Sie unter ASP.NET-Autorisierung.

Benutzerdefinierte Authentifizierung mithilfe von SOAP-Headern

Die Windows-Authentifizierungsmechanismen, einschließlich der Clientzertifikate, basieren auf dem HTTP-Transport, während SOAP transportunabhängig ist. Mit ASP.NET erstellte Webdienste verwenden SOAP über HTTP sowie HTTP-POST- und HTTP-GET-Implementierungen, die Nicht-SOAP-XML-Dokumente zurückgeben. Ein Grund für die Erstellung eines benutzerdefinierten Authentifizierungsmechanismus besteht also darin, die Authentifizierung vom Transport abzukoppeln. Dies wird erreicht, indem die Anmeldeinformationen für die Authentifizierung im SOAP-Header übergeben werden.

SOAP-Header stellen eine effiziente Methode dar, um Out-of-Band-Daten oder Informationen ohne semantischen Bezug zu einem Webdienst zu übermitteln. Im Gegensatz zum Body-Element einer SOAP-Nachricht, das die Eingabe- und Ausgabeparameter für den Webdienstbetrieb enthält, die von der Webdienstmethode übergeben werden, ist das Header-Element optional und kann folglich von der Infrastruktur verarbeitet werden. Das heißt, die Verarbeitung findet durch eine Infrastruktur statt, die für die Bereitstellung eines benutzerdefinierten Authentifizierungsmechanismus entwickelt wurde.

Eine Beschreibung einer Methode, SOAP-Header zur Authentifizierung zu verwenden, finden Sie unter Vorgehensweise: Ausführen von benutzerdefinierter Authentifizierung mit SOAP-Headern.

Wenn ein Webdienstclient SOAP-Header für die Authentifizierung verwenden möchte, sendet er seine Anmeldeinformationen an den Webdienst, indem er der SOAP-Anforderung den erwarteten SOAP-Header hinzufügt und ihn mit Clientanmeldeinformationen auffüllt. Um die SOAP-Headerauthentifizierung verwenden zu können, muss ein Webdienst zwei Bedingungen erfüllen: Er muss angeben, dass er den SOAP-Header erwartet, der die Anmeldeinformationen für die Authentifizierung enthält, und er muss den Clientzugriff auf den Webdienst autorisieren.

Siehe auch

Aufgaben

Vorgehensweise: Konfigurieren eines XML-Webdiensts zur Windows-Authentifizierung
Vorgehensweise: Ausführen von benutzerdefinierter Authentifizierung mit SOAP-Headern

Verweis

NetworkCredential
CredentialCache
X509Certificate

Weitere Ressourcen

Sichern von ASP.NET-Webanwendungen
Erstellen von XML-Webdiensten mit ASP.NET