Sichern von WCF Data Services
In diesem Thema werden spezielle Sicherheitsüberlegungen hinsichtlich der Entwicklung, Bereitstellung und Ausführung von WCF Data Services und Anwendungen beschrieben, die auf Dienste zugreifen, die das Open Data Protocol (OData) unterstützen. Neben diesen Hinweisen sollten Sie auch die Empfehlungen zum Erstellen sicherer .NET Framework-Anwendungen befolgen.
Beim Planen der Sicherheit eines WCF Data Services-basierten OData-Diensts müssen Sie sowohl die Authentifizierung (den Prozess zur Erkennung und Überprüfung der Identität eines Prinzipals) als auch die Autorisierung (den Prozess, durch den bestimmt wird, ob ein authentifizierter Prinzipal auf die angeforderten Ressourcen zugreifen kann) berücksichtigen. Sie sollten auch erwägen, die Nachricht mit SSL zu verschlüsseln.
Authentifizieren von Clientanforderungen
WCF Data Services implementiert keine eigene Authentifizierung, sondern beruht auf der Authentifizierung des Datendiensthosts. Der Dienst geht also davon aus, dass jede von ihm empfangene Anforderung bereits vom Netzwerkhost authentifiziert wurde und der Host den Prinzipal für die Anforderung anhand der von WCF Data Services bereitgestellten Schnittstellen korrekt identifiziert hat. Diese Authentifizierungsoptionen und -methoden werden unter OData und Authentifizierungsfolgen ausführlich beschrieben.
Authentifizierungsoptionen für WCF Data Services
Die folgende Tabelle enthält einige der Authentifizierungsmechanismen, die für das Authentifizieren von Anforderungen an einen WCF Data Service verfügbar sind.
Authentifizierungsoptionen |
Beschreibung |
||
|---|---|---|---|
Anonyme Authentifizierung |
Wenn die anonyme HTTP-Authentifizierung aktiviert ist, kann jeder Prinzipal eine Verbindung mit dem Datendienst herstellen. Anmeldeinformationen sind für den anonymen Zugriff nicht erforderlich. Verwenden Sie diese Option nur, wenn alle Benutzer Zugriff auf den Datendienst haben sollen. |
||
Standard- und Digestauthentifizierung |
Für die Authentifizierung sind aus Benutzername und Kennwort bestehende Anmeldeinformationen erforderlich. Unterstützt die Authentifizierung von Nicht-Windows-Clients.
Microsoft Internetinformationsdienste (IIS) stellt eine Implementierung der Standard- und Digestauthentifizierung für HTTP-Anforderungen in einer ASP.NET-Anwendung bereit. Diese Windows-Authentifizierungsanbieterimplementierung ermöglicht es einer .NET Framework-Clientanwendung, Anmeldeinformationen im HTTP-Header der Anforderung an den Datendienst bereitzustellen, um die Authentifizierung eines Windows-Benutzers problemlos auszuhandeln. Weitere Informationen finden Sie unter Technische Referenz für die Digestauthentifizierung. Wenn für den Datendienst keine Windows-Anmeldeinformationen, sondern eine Standardauthentifizierung anhand eines benutzerdefinierten Authentifizierungsdiensts verwendet werden soll, müssen Sie ein benutzerdefiniertes ASP.NET-HTTP-Modul für die Authentifizierung implementieren. Ein Beispiel zu zur Verwendung eines benutzerdefinierten Standardauthentifizierungsschemas mit WCF Data Services finden Sie im Beitrag Benutzerdefinierte Standardauthentifizierung im Thema zu OData und Authentifizierungsfolgen. |
||
Windows-Authentifizierung |
Windows-basierte Anmeldeinformationen werden mit NTLM oder Kerberos ausgetauscht. Dieser Mechanismus ist sicherer als die Standard- oder Digestauthentifizierung, erfordert jedoch, dass es sich beim Client um eine Windows-basierte Anwendung handelt. IIS stellt auch eine Implementierung der Windows-Authentifizierung für HTTP-Anforderungen in einer ASP.NET-Anwendung bereit. Weitere Informationen finden Sie unter ASP.NET Forms Authentication Overview. Ein Beispiel zu zur Verwendung der Windows-Authentifizierung mit WCF Data Services finden Sie im Beitrag Windows-Authentifizierung im Thema zu OData und Authentifizierungsfolgen. |
||
ASP.NET-Formularauthentifizierung |
Die Formularauthentifizierung ermöglicht es Ihnen, Benutzer mit eigenem Code zu authentifizieren und anschließend ein Authentifizierungstoken in einem Cookie oder in der Seiten-URL beizubehalten. Der Benutzername und das Kennwort der Benutzer werden mit einem von Ihnen erstellten Anmeldeformular authentifiziert. Nicht authentifizierte Anforderungen werden zu einer Anmeldeseite umgeleitet, auf der der Benutzer Anmeldeinformationen eingibt und das Formular übermittelt. Wenn die Anwendung die Anforderung authentifiziert, stellt das System ein Ticket aus, das einen Schlüssel zum Wiederherstellen der Identität für nachfolgende Anforderungen enthält. Weitere Informationen finden Sie unter Forms Authentication Provider.
Ein Beispiel zu zur Verwendung der Formularauthentifizierung mit WCF Data Services finden Sie im Beitrag Formularauthentifizierung im Thema zu OData und Authentifizierungsfolgen. |
||
Anspruchbasierte Authentifizierung |
Bei der anspruchbasierten Authentifizierung stützt sich der Datendienst zum Authentifizieren des Benutzers auf einen vertrauenswürdigen Drittanbieter-Identitätsanbieter. Der Identitätsanbieter nimmt eine positive Authentifizierung des Benutzers vor, der Zugriff auf Datendienstressourcen anfordert, und stellt ein Token aus, das Zugriff auf die angeforderten Ressourcen gewährt. Dieses Token wird dann an den Datendienst übergeben, und der Datendienst gewährt dem Benutzer basierend auf der Vertrauensstellung mit dem Identitätsdienst, von dem das Zugriffstoken ausgestellt wurde, Zugriff. Der Vorteil der anspruchbasierten Authentifizierung besteht darin, dass mit dieser Methode verschiedene Clienttypen vertrauensdomänenübergreifend authentifiziert werden können. Durch die Verwendung eines Drittanbieter-Identitätsanbieters kann der Datendienst die Anforderungen für die Verwaltung und Authentifizierung von Benutzern abladen. OAuth 2.0 ist ein anspruchbasiertes Authentifizierungsprotokoll, das von der Windows Azure AppFabric-Zugriffssteuerung für die Partnerautorisierung als Dienst unterstützt wird. Dieses Protokoll unterstützt REST-basierte Dienste. Ein Beispiel zu zur Verwendung von OAuth 2.0 mit WCF Data Services finden Sie im Beitrag OData und OAuth im Thema zu OData und Authentifizierungsfolgen. |
.gif "Sicherheitshinweis")
SicherheitshinweisAuthentifizierung in der Clientbibliothek
Die WCF Data Services-Clientbibliothek stellt standardmäßig keine Anmeldeinformationen bereit, wenn eine Anforderung an einen OData-Dienst gesendet wird. Wenn der Datendienst für die Authentifizierung eines Benutzers Anmeldeinformationen erfordert, können diese Anmeldeinformationen wie im folgenden Beispiel in einem NetworkCredential-Objekt bereitgestellt werden, auf das von der Credentials-Eigenschaft des DataServiceContext zugegriffen wird:
' Set the client authentication credentials.
context.Credentials = _
New NetworkCredential(userName, password, domain)
// Set the client authentication credentials.
context.Credentials =
new NetworkCredential(userName, password, domain);
Weitere Informationen finden Sie unter Vorgehensweise: Angeben von Clientanmeldeinformationen für eine Datendienstanforderung (WCF Data Services).
Wenn der Datendienst Anmeldeinformationen erfordert, die nicht mithilfe eines NetworkCredential-Objekts angegeben werden können (z. B. ein anspruchbasiertes Token oder Cookie), müssen Sie manuell Header in der HTTP-Anforderung festlegen (normalerweise die Header Authorization und Cookie). Weitere Informationen zu diesem Authentifizierungsszenario finden Sie im Beitrag OData und Authentifizierung: Clientseitige Hooks. Ein Beispiel zum Festlegen von HTTP-Headern in einer Anforderungsnachricht finden Sie unter Vorgehensweise: Festlegen von Headern in der Clientanforderung (WCF Data Services).
Identitätswechsel
Im Allgemeinen greift der Datendienst anhand der Anmeldeinformationen des Arbeitsprozesses, der den Datendienst hostet, auf erforderliche Ressourcen zu (z. B. Dateien auf dem Server oder eine Datenbank). Mithilfe eines Identitätswechsels können ASP.NET-Anwendungen unter der Windows-Identität (Benutzerkonto) des Benutzers ausgeführt werden, der die Anforderung sendet. Ein Identitätswechsel wird für gewöhnlich in Anwendungen verwendet, bei denen die Benutzerauthentifizierung über IIS erfolgt und die Anmeldeinformationen dieses Prinzipals für den Zugriff auf die benötigten Ressourcen verwendet werden. Weitere Informationen finden Sie unter ASP.NET Impersonation.
Konfigurieren der Datendienstautorisierung
Durch die Autorisierung wird einem Prinzipal oder Prozess, der mittels einer vorherigen erfolgreichen Authentifizierung identifiziert wurde, Zugriff auf Anwendungsressourcen gewährt. Im Allgemeinen sollten Benutzern des Datendiensts nur die Rechte gewährt werden, die zur Ausführung der von Clientanwendungen benötigten Vorgänge erforderlich sind.
Einschränken des Zugriffs auf Datendienstressourcen
Standardmäßig können Sie in WCF Data Services jedem Benutzer, der auf den Datendienst zugreifen kann, allgemeinen Lese- und Schreibzugriff auf Datendienstressourcen gewähren (Entitätenmengen und Dienstvorgänge). Für jede vom Datendienst verfügbar gemachte Entitätenmenge und alle Dienstvorgänge können separat Regeln zum Definieren des Lese- und Schreibzugriffs eingerichtet werden. Es wird empfohlen, sowohl den Lese- als auch den Schreibzugriff auf die Ressourcen zu beschränken, die von der Clientanwendung benötigt werden. Weitere Informationen finden Sie unter Configuring the Data Service (WCF Data Services).
Implementieren rollenbasierter Interceptors
Interceptors ermöglichen es Ihnen, Anforderungen für Datendienstressourcen abzufangen, bevor sie vom Datendienst verarbeitet werden. Weitere Informationen finden Sie unter Interceptoren (WCF Data Services). Mithilfe von Interceptors können Sie Autorisierungsentscheidungen auf Grundlage des authentifizierten Benutzers treffen, von dem die Anforderung stammt. Ein Beispiel zu zur Beschränkung des Zugriffs auf Datendienstressourcen, die auf einer authentifizierten Benutzeridentität basieren, finden Sie unter Gewusst wie: Abfangen von Datendienstnachrichten (WCF Data Services).
Einschränken des Zugriffs auf den persistenten Datenspeicher und lokale Ressourcen
Den für den Zugriff auf den persistenten Datenspeicher verwendeten Konten sollten nur die Rechte für eine Datenbank oder das Dateisystem gewährt werden, die zum Erfüllen der Anforderungen des Datendiensts erforderlich sind. Bei Verwendung der anonymen Authentifizierung ist dies das Konto, unter dem die Hostanwendung ausgeführt wird. Weitere Informationen finden Sie unter Vorgehensweise: Entwickeln eines WCF-Datendiensts, der auf IIS ausgeführt wird. Wenn Identitätswechsel verwendet werden, muss authentifizierten Benutzern Zugriff auf diese Ressourcen gewährt werden (dazu wird normalerweise eine Windows-Gruppe verwendet).
Sonstige Sicherheitsüberlegungen
Sichern der Daten in der Nutzlast
OData beruht auf dem HTTP-Protokoll. Abhängig von der vom Datendienst implementierten Authentifizierung kann der Header in einer HTTP-Nachricht wertvolle Benutzeranmeldeinformationen enthalten. Der Nachrichtentext kann ebenfalls wichtige Kundendaten enthalten, die geschützt werden müssen. In beiden Fällen wird empfohlen, den Austausch dieser Informationen mit SSL zu schützen.
Ignorierte Nachrichtenheader und Cookies
Mit Ausnahme der Header, die Inhaltstypen und Ressourcenpfade deklarieren, werden HTTP-Anforderungsheader ignoriert und nie vom Datendienst festgelegt.
Cookies können als Teil eines Authentifizierungsschemas verwendet werden, z. B. mit der ASP.NET-Formularauthentifizierung. Alle für eine eingehende Anforderung festgelegten HTTP-Cookies werden jedoch von WCF Data Services ignoriert. Der Host eines Datendiensts kann das Cookie verarbeiten, Cookies werden aber nie von der WCF Data Services-Runtime analysiert oder zurückgegeben. In der Antwort gesendete Cookies werden auch nicht von der WCF Data Services-Clientbibliothek verarbeitet.
Benutzerdefinierte Hostanforderungen
WCF Data Services wird standardmäßig als eine in IIS gehostete ASP.NET-Anwendung erstellt. Dies ermöglicht es dem Datendienst, die sicheren Verhalten dieser Plattform zu nutzen. Sie können WCF Data Services definieren, die von einem benutzerdefinierten Host gehostet werden. Weitere Informationen finden Sie unter Hosten des Datendiensts (WCF Data Services). Die Komponenten und die Plattform, von denen ein Datendienst gehostet wird, müssen Angriffe auf den Datendienst durch die folgenden Sicherheitsverhalten verhindern:
Begrenzen Sie die Länge des in einer Datendienstanforderung akzeptierten URI für alle möglichen Vorgänge.
Begrenzen Sie die Größe ein- und ausgehender HTTP-Nachrichten.
Begrenzen Sie die Gesamtanzahl von Anforderungen, die gleichzeitig ausstehen können.
Begrenzen Sie die Größe von HTTP-Headern und den zugehörigen Werten, und gewähren Sie WCF Data Services Zugriff auf Headerdaten.
Richten Sie eine Erkennung und Verteidigungsmaßnahmen für bekannte Angriffe wie TCP-SYN und Nachrichtenreplay ein.
Keine weitere Codierung von Werten
An den Datendienst gesendete Eigenschaftenwerte werden von der WCF Data Services-Runtime nicht weiter codiert. Wenn z. B. eine string-Eigenschaft einer Entität formatierten HTML-Inhalt enthält, werden die Tags vom Datendienst nicht HTML-codiert. Eigenschaftenwerte in der Antwort werden vom Datendienst ebenfalls nicht weiter codiert. Von der Clientbibliothek wird auch keine zusätzliche Codierung ausgeführt.
Überlegungen für Clientanwendungen
Die folgenden Sicherheitsüberlegungen gelten für Anwendungen, die mithilfe des WCF Data Services-Clients auf OData-Dienste zugreifen:
Die Clientbibliothek geht davon aus, dass die für den Zugriff auf den Datendienst verwendeten Protokolle eine geeignete Sicherheitsebene bereitstellen.
Die Clientbibliothek verwendet alle Standardwerte für Timeouts und Analyseoptionen der Transportstapel der zugrunde liegenden Plattform.
Die Clientbibliothek liest keine Einstellungen aus Anwendungskonfigurationsdateien.
Die Clientbibliothek implementiert keine domänenübergreifenden Zugriffsmechanismen. Sie verwendet stattdessen die vom zugrunde liegenden HTTP-Stapel bereitgestellten Mechanismen.
Die Clientbibliothek verfügt nicht über Benutzeroberflächenelemente und versucht nie, die empfangenen oder gesendeten Daten anzuzeigen oder zu rendern.
Benutzereingaben und akzeptierte Daten von nicht vertrauenswürdigen Diensten sollten immer von Clientanwendungen überprüft werden.