Freigeben über

Nicht unterstützte Szenarien

  • Artikel

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 integrierte HTTP/HTTPS-Authentifizierung, werden beim Ausführen von WCF unter Windows XP Home Edition unterstützt.

Identitätswechselszenarien

Keine Weitergabe der angenommenen 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.

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.

  • Für die Eigenschaft Impersonation des OperationBehaviorAttribute wird der Wert 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 Gewusst wie: Erstellen eines Tokens für den Sicherheitskontext einer sicheren Sitzung. Im Code wird das Token aktiviert, indem ein Sicherheitsbindungselement (SymmetricSecurityBindingElement oder AsymmetricSecurityBindingElement) erstellt wird. Dazu wird die Methode SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) oder die Methode SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) verwendet und der Parameter requireCancellation auf false festgelegt. 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, dann ein <security>-Element hinzugefügt und das authenticationMode-Attribut auf „SecureConversation“ 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 eine WCF-Anwendung hostet, kann ein Konflikt zwischen den WCF- und den ASP.NET-Konfigurationseinstellungen vorliegen. Bei einem Konflikt hat die WCF-Einstellung Vorrang, es sei denn, die Impersonation-Eigenschaft ist auf NotAllowed festgelegt. In diesem Fall wird die ASP.NET-Identitätswechseleinstellung vorrangig behandelt.

Assemblyladevorgä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 Benutzerkontexts 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.

Delegierung erfordert Aushandlung der Anmeldeinformationen

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 zum Implementieren der Aushandlung von Anmeldeinformationen finden Sie unter Debuggen von Windows-Authentifizierungsfehlern.

Kryptografie

Unterstützung von SHA-256 nur für den Einsatz mit symmetrischen Schlüsseln

WCF unterstützt mehrere Verschlüsselungsalgorithmen und Algorithmen zur Signaturdigesterstellung, die Sie mit der Algorithmussammlung in den vom System bereitgestellten Bindungen festlegen können. Für eine höhere Sicherheit unterstützt WCF Secure Hash 2-Algorithmen (SHA), vor allem SHA-256, für die Erstellung von Signaturdigesthashes. Dieses Release 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 der derzeit fehlenden Unterstützung für RSA-SHA256 in WinFX.

Keine Unterstützung für FIPS-konforme SHA-256-Hashes

WCF unterstützt keine SHA-256-FIPS-konformen Hashes, sodass Algorithmussammlungen, die SHA-256 verwenden, von WCF nicht auf Systemen unterstützt werden, bei denen der Einsatz FIPS-konformer Algorithmen erforderlich ist.

FIPS-konforme Algorithmen schlagen beim Bearbeiten der Registrierung möglicherweise fehl

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 die Verwendung 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.

Einschränkungen bei der FIPS-konformen AES-Verschlüsselung

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

CNG-/KSP-Zertifikate

Die API Cryptography Next Generation (CNG) ist der langfristige Ersatz für die CryptoAPI. Diese API ist in nicht verwaltetem Code unter Windows Vista, Windows Server 2008 und höheren Windows-Versionen verfügbar.

.NET Framework 4.6.1 und frühere Versionen unterstützen diese Zertifikate nicht, weil sie die ältere CryptoAPI zum Verarbeiten von CNG-/KSP-Zertifikaten verwenden. Die Verwendung dieser Zertifikate mit .NET Framework 4.6.1 und früheren Versionen führt zu einer 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 an der Eingabeaufforderung. Weitere Informationen finden Sie unter Aufgaben von Certutil für die Problembehandlung bei Zertifikaten.

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

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

  • Der ASP.NET-Identitätswechsel wird aktiviert. Hierzu wird in der Datei „Web.config“ das Attribut impersonate des <identity>-Elements auf true festgelegt.

  • Der ASP.NET-Kompatibilitätsmodus wird aktiviert, indem das Attribut aspNetCompatibilityEnabled von <serviceHostingEnvironment> auf true festgelegt wird.

  • Die Nachrichtenmodussicherheit wird verwendet.

Die Problemumgehung besteht darin, den ASP.NET-Kompatibilitätsmodus zu deaktivieren. Wenn der ASP.NET-Kompatibilitätsmodus erforderlich ist, können Sie das ASP.NET-Identitätswechselfeature deaktivieren und stattdessen den von WCF bereitgestellten Identitätswechsel verwenden. Weitere Informationen finden Sie unter Delegierung und Identitätswechsel.

Fehler bei IPv6-Literaladressen

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 Verbundvertrauensstellung

WCF erfordert für jeden Knoten in der Verbundvertrauenskette 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:

  • http://localhost/CalculatorService/service (der Dienst)

  • http://localhost/CalculatorService/issue_ticket (der STS)

  • http://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 gehen

WCF kann die Attribute eines <wst:Claims>-Vorlage beim Ausführen eines WSDL-Imports nicht verfolgen. Dieses Problem tritt im Zuge eines WSDL-Importvorgangs auf, wenn <Claims>WSFederationHttpBinding.Security.Message.TokenRequestParameters 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