Unsupported Scenarios
For various reasons, Windows Communication Foundation (WCF) does not support some specific security scenarios. For example, Windows XP Home Edition does not implement the SSPI or Kerberos authentication protocols, and therefore WCF does not support running a service with Windows authentication on that platform. Other authentication mechanisms, such as username/password and HTTP/HTTPS integrated authentication are supported when running WCF under Windows XP Home Edition.
Impersonation Scenarios
Impersonated Identity Might Not Flow When Clients Make Asynchronous Calls
When a WCF client makes asynchronous calls to a WCF service using Windows authentication under impersonation, authentication might occur with the identity of the client process instead of the impersonated identity.
Windows XP and Secure Context Token Cookie Enabled
WCF does not support impersonation and an InvalidOperationException is thrown when the following conditions exist:
The operating system is Windows XP.
The authentication mode results in a Windows identity.
The Impersonation property of the OperationBehaviorAttribute is set to Required.
A state-based security context token (SCT) is created (by default, creation is disabled).
The state-based SCT can only be created using a custom binding. For more information, see How to: Create a Stateful Security Context Token for a Secure Session.) In code, the token is enabled by creating a security binding element (either SymmetricSecurityBindingElement or AsymmetricSecurityBindingElement) using the System.ServiceModel.Channels.SecurityBindingElement.CreateSspiNegotiationBindingElement(System.Boolean) or the System.ServiceModel.Channels.SecurityBindingElement.CreateSecureConversationBindingElement(System.ServiceModel.Channels.SecurityBindingElement,System.Boolean) method and setting the requireCancellation parameter to false. The parameter refers to the caching of the SCT. Setting the value to false enables the state-based SCT feature.
Alternatively, in configuration, the token is enabled by creating a <customBinding>, then adding a <security> element, and setting the authenticationMode attribute to SecureConversation and the requireSecurityContextCancellation attribute to true.
Note
The preceding requirements are specific. For example, the CreateKerberosBindingElement creates a binding element that results in a Windows identity, but does not establish an SCT. Therefore, you can use it with the Required option on Windows XP.
Possible ASP.NET Conflict
WCF and ASP.NET can both enable or disable impersonation. When ASP.NET hosts an WCF application, a conflict may exist between the WCF and ASP.NET configuration settings. In case of conflict, the WCF setting takes precedence, unless the Impersonation property is set to NotAllowed, in which case the ASP.NET impersonation setting takes precedence.
Assembly Loads May Fail Under Impersonation
If the impersonated context does not have access rights to load an assembly and if it is the first time the common language runtime (CLR) is attempting to load the assembly for that AppDomain, the AppDomain caches the failure. Subsequent attempts to load that assembly (or assemblies) fail, even after reverting the impersonation, and even if the reverted context has access rights to load the assembly. This is because the CLR does not re-attempt the load after the user context is changed. You must restart the application domain to recover from the failure.
Note
The default value for the AllowedImpersonationLevel property of the WindowsClientCredential class is Identification. In most cases, an identification-level impersonation context has no rights to load any additional assemblies. This is the default value, so this is a very common condition to be aware of. Identification-level impersonation also occurs when the impersonating process does not have the SeImpersonate privilege. For more information, see Delegation and Impersonation with WCF.
Delegation Requires Credential Negotiation
To use the Kerberos authentication protocol with delegation, you must implement the Kerberos protocol with credential negotiation (sometimes called multi-leg or multi-step Kerberos). If you implement Kerberos authentication without credential negotiation (sometimes called one-shot or single-leg Kerberos), an exception is thrown. For more information about how to implement credential negotiation, see Debugging Windows Authentication Errors.
Cryptography
SHA-256 Supported Only for Symmetric Key Usages
WCF supports a variety of encryption and signature digest creation algorithms that you can specify using the algorithm suite in the system-provided bindings. For improved security, WCF supports Secure Hash Algorithm (SHA) 2 algorithms, specifically SHA-256, for creating signature digest hashes. This release supports SHA-256 only for symmetric key usages, such as Kerberos keys, and where an X.509 certificate is not used to sign the message. WCF does not support RSA signatures (used in X.509 certificates) using SHA-256 hash due to the current lack of support for RSA-SHA256 in the .NET Framework 3.0.
FIPS-Compliant SHA-256 Hashes not Supported
WCF does not support SHA-256 FIPS-compliant hashes, so algorithm suites that use SHA-256 are not supported by WCF on systems where use of FIPS compliant algorithms is required.
FIPS-Compliant Algorithms May Fail if Registry Is Edited
You can enable and disable Federal Information Processing Standards (FIPS)-compliant algorithms by using the Local Security Settings Microsoft Management Console (MMC) snap-in. You can also access the setting in the registry. Note, however, that WCF does not support using the registry to reset the setting. If the value is set to anything other than 1 or 0, inconsistent results can occur between the CLR and the operating system.
FIPS-Compliant AES Encryption Limitation
FIPS compliant AES encryption does not work in duplex callbacks under identification level impersonation.
CNG/KSP Certificates on Windows Server 2008
Cryptography API: Next Generation (CNG) is the long-term replacement for the CryptoAPI. This API is available in unmanaged code on Windows Vista and Windows Server 2008.
On down-level platforms (Windows Server 2003 and Windows XP) .NET Framework 2.0 does not recognize this protocol, and instead uses the legacy CryptoApi to handle CNG/KSP certificates. On Windows Server 2008 and Windows Vista, .NET Framework 3.5 does not support these certificates: their use causes an exception.
There are two possible ways to tell if a certificate uses KSP:
Do a p/invoke of CertGetCertificateContextProperty, and inspect dwProvType on the returned CertGetCertificateContextProperty.
Use the certutil command from the command line for querying certificates. For more information, see Certutil tasks for troubleshooting certificates.
Message Security Fails if Using ASP.NET Impersonation and ASP.NET Compatibility Is Required
WCF does not support the following combination of settings because they can prevent client authentication from occurring:
ASP.NET Impersonation is enabled. This is done in the Web.config file by setting the impersonate attribute of the <identity> element to true.
ASP.NET compatibility mode is enabled by setting the aspNetCompatibilityEnabled attribute of the <serviceHostingEnvironment> element to true.
Message mode security is used.
The work-around is to turn off the ASP.NET compatibility mode. Or, if the ASP.NET compatibility mode is required, disable the ASP.NET impersonation feature and use WCF-provided impersonation instead. For more information, see Delegation and Impersonation with WCF.
IPv6 Literal Address Failure
Security requests fail when the client and service are on the same machine, and IPv6 literal addresses are used for the service.
Literal IPv6 addresses work if the service and client are on different machines.
WSDL Retrieval Failures with Federated Trust
WCF requires exactly one WSDL document for each node in the federated trust chain. Be careful not to set up a loop when specifying endpoints. One way in which loops can arise is using a WSDL download of federated trust chains with two or more links in the same WSDL document. A common scenario that can produce this problem is a federated service where the Security Token Server and the service are contained inside the same ServiceHost.
An example of this situation is a service with the following three endpoint addresses:
https://localhost/CalculatorService/service (the service)
https://localhost/CalculatorService/issue_ticket (the STS)
https://localhost/CalculatorService/mex (the metadata endpoint)
This throws an exception.
You can make this scenario work by putting the issue_ticket endpoint elsewhere.
WSDL Import Attributes can be Lost
WCF loses track of the attributes on a <wst:Claims> element in an RST template when doing a WSDL import. This happens during a WSDL import if you specify <Claims> directly in WSFederationHttpBinding.Security.Message.TokenRequestParameters or IssuedSecurityTokenRequestParameters.AdditionalRequestParameters instead of using the claim type collections directly. Since the import loses the attributes, the binding doesn't round trip properly through WSDL and hence is incorrect on the client side.
The fix is to modify the binding directly on the client after doing the import.
See Also
Concepts
Information Disclosure
Elevation of Privilege
Denial of Service
Tampering
Replay Attacks