Nicht unterstützte Szenarien

Aus verschiedenen Gründen unterstützt Windows Communication Foundation (WCF) einige bestimmte Sicherheitsszenarien nicht. Beispielsweise implementiert Windows XP Home Edition die SSPI- oder Kerberos-Authentifizierungsprotokolle nicht, weshalb WCF auch die Ausführung eines Diensts mit der Windows-Authentifizierung auf dieser Plattform nicht unterstützt. Andere Authentifizierungsmechanismen, beispielsweise Benutzername/Kennwort und die HTTP/HTTPS-integrierte Authentifizierung, werden beim Ausführen von WCF unter Windows XP Home Edition unterstützt.

Identitätswechselszenarien

Keine Weitergabe der gewechselten Identität bei asynchronen Aufrufen am Client

Wenn ein WCF-Client unter Verwendung der Windows-Authentifizierung mit einem Identitätswechsel asynchrone Aufrufe eines WCF-Dienstes ausführt, kann die Authentifizierung mit der Identität des Clientprozesses anstelle der gewechselten Identität erfolgen.

Windows XP und Sicherheitskontexttoken-Cookie aktiviert

WCF unterstützt keinen Identitätswechsel, und unter den folgenden Bedingungen wird eine InvalidOperationException ausgelöst:

• Das Betriebssystem ist Windows XP.

• Der Authentifizierungsmodus ruft eine Windows-Identität hervor.

• Die Impersonation-Eigenschaft des OperationBehaviorAttribute ist auf Required festgelegt.

• Ein statusbasiertes Sicherheitszustandskontexttoken (SCT) wird erstellt. (Standardmäßig ist die Erstellung deaktiviert.)

Das statusbasierte SCT kann nur mit einer benutzerdefinierten Bindung erstellt werden. Weitere Informationen finden Sie unter Vorgehensweise: Erstellen eines Tokens für den Sicherheitskontext einer sicheren Sitzung.) Im Code wird das Token aktiviert, indem ein Sicherheitsbindungselement erstellt wird (SymmetricSecurityBindingElement oder AsymmetricSecurityBindingElement), wobei die System.ServiceModel.Channels.SecurityBindingElement.CreateSspiNegotiationBindingElement(System.Boolean)-Methode oder die System.ServiceModel.Channels.SecurityBindingElement.CreateSecureConversationBindingElement(System.ServiceModel.Channels.SecurityBindingElement,System.Boolean)-Methode verwendet wird und der requireCancellation-Parameter auf false festgelegt wird. Der Parameter bezieht sich auf die Zwischenspeicherung des SCT. Wenn Sie den Wert auf false festlegen, wird die statusbasierte SCT-Funktion aktiviert.

Alternativ wird das Token in der Konfiguration aktiviert, indem eine <customBinding> erstellt, ein <security>-Element hinzugefügt, das authenticationMode-Attribut auf "SecureConversation" festgelegt und das requireSecurityContextCancellation-Attribut auf true festgelegt wird.

Hinweis:
Die zuvor genannten Anforderungen sind spezifisch. Beispielsweise erstellt das CreateKerberosBindingElement ein Bindungselement, das zu einer Windows-Identität führt, wobei aber kein SCT eingerichtet wird. Sie können es daher mit der Required-Option unter Windows XP verwenden.

Möglicher ASP.NET-Konflikt

WCF und ASP.NET können beide den Identitätswechsel aktivieren oder deaktivieren. Wenn ASP.NET Host für eine WCF-Anwendung ist, kann ein Konflikt zwischen der WCF-Konfigurationseinstellung und der ASP.NET-Konfigurationseinstellung auftreten. Bei einem Konflikt hat die WCF-Einstellung Vorrang, es sei denn die Impersonation-Eigenschaft ist auf NotAllowed festgelegt, wobei in diesem Fall die ASP.NET-Identitätswechseleinstellung Vorrang hat.

Assembly-Ladevorgänge können beim Identitätswechsel fehlschlagen

Wenn der Identitätswechselkontext keine Zugriffsberechtigungen zum Laden einer Assembly hat und es das erste Mal ist, dass die Common Language Runtime (CLR) versucht, die Assembly für diese Anwendungsdomäne zu laden, speichert die AppDomain den Fehler zwischen. Nachfolgende Versuche, diese Assembly(s) zu laden, schlagen fehl, selbst nach dem Zurücksetzen des Identitätswechsels und sogar wenn der zurückgesetzte Kontext die Zugriffsberechtigungen hat, die Assembly zu laden. Die Ursache dafür ist, dass die CLR nach der Änderung des Benutzerkontextes keinen weiteren Ladeversuch unternimmt. Sie müssen die Anwendungsdomäne neu starten, um nach dem Fehler wiederhergestellt zu werden.

Hinweis:

Der Standardwert für die AllowedImpersonationLevel-Eigenschaft der WindowsClientCredential-Klasse ist Identification. In den meisten Fällen hat ein Identitätswechsel auf Identifizierungsebene nicht die Berechtigung, zusätzliche Assemblys zu laden. Dies ist der Standardwert. Es handelt sich somit um eine sehr übliche Bedingung, derer Sie sich bewusst sein sollten. Der Identitätswechsel auf Identifizierungsebene kann auch dann auftreten, wenn der Identitätswechselvorgang nicht die SeImpersonate-Berechtigung hat. Weitere Informationen finden Sie unter Delegierung und Identitätswechsel mit WCF.

Delegierung erfordert eine Anmeldeinformationen-Aushandlung

Um das Kerberos-Authentifizierungsprotokoll mit Delegierung zu verwenden, müssen Sie das Kerberos-Protokoll mit Anmeldeinformationen-Aushandlung (mitunter als bilaterales oder mehrstufiges Kerberos bezeichnet) implementieren. Wenn Sie die Kerberos-Authentifizierung ohne Anmeldeinformationen-Aushandlung (mitunter als One-Shot-Kerberos bezeichnet) implementieren, wird eine Ausnahme ausgelöst. Weitere Informationen über über die Implementierung der Anmeldeinformationen-Aushandlung finden Sie unter Debuggen von Windows-Authentifizierungsfehlern.

Kryptografie

Unterstützt HA-256 nur für den Einsatz mit symmetrischen Schlüsseln

WCF unterstützt mehrere Verschlüsselungsalgorithmen und Signatur-Digest-Erstellungsalgorithmen, die Sie mit der Algorithmussuite in den vom System bereitgestellten Bindungen festlegen können. Für eine höhere Sicherheit unterstützt WCF Secure Hash Algorithm (SHA) 2-Algorithmen, vor allem SHA-256, für die Erstellung von Signatur-Digest-Hashes. Diese Version unterstützt SHA-256 nur für Einsätze mit symmetrischen Schlüsseln, z. B. Kerberos-Schlüssel und wenn kein X.509-Zertifikat zum Signieren der Nachricht verwendet wird. WCF unterstützt keine RSA-Signaturen (in X.509-Zertifikaten) mit SHA-256-Hash aufgrund des derzeitigen fehlenden Supports für RSA-SHA256 in .NET Framework 3.0.

FIPS-kompatible SHA-256-Hashes werden nicht unterstützt

WCF unterstützt keine SHA256-FIPS-kompatiblen Hashes, sodass Algorithmussuites, die SHA256 verwenden, von WCF nicht auf Systemen unterstützt werden, bei denen der Einsatz von FIPS-kompatiblen Algorithmen erforderlich ist.

FIPS-kompatible Algorithmen schlagen ggf. fehl, wenn die Registrierung bearbeitet wird

Sie können Federal Information Processing Standards (FIPS)-kompatible Algorithmen aktivieren und deaktivieren, indem Sie das Snap-In Lokale Sicherheitseinstellungen der Microsoft Management Console (MMC) verwenden. Sie können auch auf die Einstellung in der Registrierung zugreifen. Beachten Sie jedoch, dass WCF nicht den Einsatz der Registrierung zum Zurücksetzen der Einstellung unterstützt. Wenn ein anderer Wert als 1 oder 0 festgelegt wurde, können zwischen CLR und dem Betriebssystem inkonsistente Ergebnisse auftreten.

FIPS-kompatible AES-Verschlüsselungseinschränkungen

Die FIPS-kompatible AES-Verschlüsselung funktioniert nicht bei Duplexrückrufen unter dem Identitätswechsel auf Identifizierungsebene.

CNG-/KSP-Zertifikate unter Windows Server 2008

Kryptografie-API: Next Generation (CNG) ist der langfristige Ersatz für die CryptoAPI. Diese API ist in nicht verwaltetem Code unter Windows Vista und unter Windows Server 2008 verfügbar.

Unter älteren Plattformen (Windows Server 2003 und Windows XP) erkennt .NET Framework 2.0 dieses Protokoll nicht und verwendet stattdessen die ältere CryptoAPI für die Behandlung von CNG-/KSP-Zertifikaten. Unter Windows Server 2008 und Windows Vista unterstützt .NET Framework 3.5 diese Zertifikate nicht: ihre Verwendung verursacht eine Ausnahme.

Ob KSP von einem Zertifikat verwendet wird, kann auf zwei Arten ermittelt werden:

• Führen Sie p/invoke für die CertGetCertificateContextProperty aus, und überprüfen Sie dwProvType in der zurückgegebenen CertGetCertificateContextProperty.

• Verwenden Sie zum Abfragen von Zertifikaten den certutil-Befehl in der Eingabeaufforderung. Weitere Informationen finden Sie unter Aufgaben von Certutil für die Problembehandlung bei Zertifikaten (möglicherweise in englischer Sprache).

Nachrichtensicherheit schlägt fehlt, wenn der ASP.NET-Identitätswechsel verwendet wird und die ASP.NET-Kompatibilität erforderlich ist

WCF unterstützt die folgende Kombination an Einstellungen, da sie die Durchführung der Clientauthentifizierung verhindern können:

• ASP.NET-Identitätswechsel ist aktiviert. Dies wird in der Web.config-Datei durchgeführt, indem das impersonate-Attribut des <identity>-Elements auf true festgelegt wird.

• Der ASP.NET-Kompatibilitätsmodus wird aktiviert, indem das aspNetCompatibilityEnabled-Attribut des <serviceHostingEnvironment> elementtrue auf gesetzt wird.

• Die Nachrichtenmodussicherheit wird verwendet.

Sie können alternativ auch den ASP.NET-Kompatibilitätsmodus deaktivieren. Oder wenn der ASP.NET-Kompatibilitätsmodus erforderlich ist, können Sie die ASP.NET-Identitätswechselfunktion deaktivieren und stattdessen den von WCF bereitgestellten Identitätswechsel verwenden. Weitere Informationen finden Sie unter Delegierung und Identitätswechsel mit WCF.

IPv6-Literal-Adressfehler

Bei Sicherheitsanforderungen tritt ein Fehler auf, wenn sich Client und Dienst auf dem gleichen Computer befinden und für den Dienst IPv6-Literaladressen verwendet werden.

IPv6-Literal-Adressen funktionieren, wenn der Dienst und der Client sich auf unterschiedlichen Computern befinden.

WSDL-Abruffehler bei Verbundvertrauen

WCF erfordert für jeden Knoten in der Vertrauenskette des Verbunds genau ein WSDL-Dokument. Achten Sie darauf, beim Angeben von Endpunkten keine Schleife einzurichten. Eine Schleife kann beispielsweise bei Verwendung eines WSDL-Downloads von Vertrauensketten des Verbunds entstehen, wenn das gleiche WSDL-Dokument mehrere Links enthält. Ein häufig auftretendes Szenario für dieses Problem ist ein Verbunddienst, bei dem sich der Sicherheitstokenserver und der Dienst im gleichen ServiceHost befinden.

Ein Beispiel für diese Situation ist ein Dienst mit den folgenden drei Endpunktadressen:

• "https://localhost/CalculatorService/service" (der Dienst)

• "https://localhost/CalculatorService/issue_ticket" (der STS)

• "https://localhost/CalculatorService/mex" (der Metadatenendpunkt)

Dadurch wird eine Ausnahme ausgelöst.

Verlegen Sie den issue_ticket-Endpunkt, damit dieses Szenario funktioniert.

WSDL-Importattribute können verloren werden

WCF kann die Attribute eines <wst:Claims>RST-Elements in einer -Vorlage beim Ausführen eines WSDL-Imports nicht verfolgen. Dieses Problem tritt im Zuge eines WSDL-Importvorgangs auf, wenn <Claims>WSFederationHttpBinding.Security.Message.TokenRequestParameters direkt in IssuedSecurityTokenRequestParameters.AdditionalRequestParameters oder in und nicht unter direkter Verwendung der Anspruchstypauflistungen angegeben werden. Da die Attribute beim Importieren verloren gehen, verläuft der Roundtrip der Bindung durch WSDL nicht ordnungsgemäß, und die Bindung ist auf der Clientseite ungültig.

Ändern Sie nach Abschluss des Importvorgangs die Bindung direkt auf dem Client, um dieses Problem zu korrigieren.

Siehe auch

Konzepte

Veröffentlichung von Informationen
Ausweitung von Berechtigungen
Dienstverweigerung
Verfälschungen
Wiederholungsangriffe

Weitere Ressourcen

Sicherheitsüberlegungen