Known Issues

  • Article

[Starting with the .NET Framework 4.5, Windows Identity Foundation (WIF) has been fully integrated into the .NET Framework. The version of WIF addressed by this topic, WIF 3.5, is deprecated and should only be used when developing against the .NET Framework 3.5 SP1 or the .NET Framework 4. For more information about WIF in the .NET Framework 4.5, also known as WIF 4.5, see the Windows Identity Foundation documentation in the .NET Framework 4.5 Development Guide.]

This topic discusses known issues in the Windows® Identity Foundation (WIF) together with existing workarounds.

ASP.NET Detects Passive Federation Tokens as Potential Security Attack

Symptom

Passive federation scenarios fail with the following error message at the relying party application.

A potentially dangerous Request.Form value was detected from the client…

Description: Request Validation has detected a potentially dangerous client input value, and processing of the request has been aborted. This value may indicate an attempt to compromise the security of your application, such as a cross-site scripting attack. You can disable request validation by setting validateRequest=false in the Page directive or in the configuration section. However, it is strongly recommended that your application explicitly check all inputs in this case.

Cause

During passive federation scenarios that use the WIF FederatedPassiveSignIn control, security tokens are passed back to relying party applications as a string. ASP.NET detects these token as potential attacks on the Web site, and puts an end to request processing as a precautionary measure.

Workaround

Disable the ASP.NET request validation feature. To do so, in Web page's .aspx file, set the Page ValidateRequest setting that is shown here.

<%@ Page ValidateRequest="false"%>

Alternately, in the Web application's Web.config file, set the validateRequest attribute of the <pages/> section to false.

<configuration>
    <system.web>
        <pages validateRequest="false" />
    </system.web>
</configuration>

Note

ASP.NET request validation is designed to help reduce the risk of cross-site scripting attacks for Web pages and ASP.NET applications. An application that does not correctly validate user input can suffer from many types of malformed input attacks. These include cross-site scripting and SQL Server injection attacks. There is no substitute for carefully evaluating all forms of input in an application and making sure that they are either correctly validated or encoded, or that the application is escaped before manipulating data or sending information back to the client. For more information about cross-site scripting, see the malicious HTML tags notice from the Carnegie Mellon University Computer Emergency Readiness Team (CERT) site. For more information about request validation, see the www.asp.net white paper about request validation.

SVCUtil Throws Exception

Symptom

If you have a WCF-based relying party that is configured with a federation binding where the issuer address points to an STS that has 5 or more end points and was built using WIF, and you run svcutil.exe against the relying party, it throws the following exception:

Microsoft (R) Service Model Metadata Tool
[Microsoft (R) Windows (R) Communication Foundation, Version 3.0.4506.2088]
Copyright (c) Microsoft Corporation.  All rights reserved.

Attempting to download metadata from 'https://localhost:8008/RP/mex' using WS-Metadata Exchange or DISCO.
Error: Obtaining metadata from issuer 'https://localhost:8000/Sts/mex' failed with error 'System.InvalidOperationException: Metadata contains a reference that cannot be resolved: 'https://localhost:8000/Sts/mex'. ---> System.ServiceModel.CommunicationException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element. ---> System.ServiceModel.QuotaExceededException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.

Cause

Svcutil.exe is a tool that ships with .NET Framework version 3.5 and can be used to generate a proxy and configuration to talk to a Web Service by downloading the service’s WSDL. The tool can generate proxies for services that federate with a Security Token Service (STS) as well. By default, the tool can download only a WSDL that is 64 KB in size. An STS with five or more end points produces a WSDL that is greater than 64 KB and hence a “max message size” exception is thrown.

Workaround

You can configure svcutil.exe to increase the size limit. Svcutil.exe.config is a sample configuration that ships with WIF and can be found in the WIF installation folder. This sample configuration lets svcutil.exe read up to 64 MB of WSDL produced by an STS. The configuration covers all four transports (http, https, net.tcp and net.pipe) over which WSDL can be exposed in WCF and increases the WSDL size limit on all of them. To use this configuration file, copy this configuration to the same directory as svcutil.exe and then run svcutil.exe. Note that this issue does not occur for Windows CardSpace clients.

CustomAuthorizationManager No Longer Works After You Enable Windows Identity Foundation in your WCF Applications

Symptom

If you have already implemented a CustomAuthorizationManager then it will no longer work once you enable WIF using ConfigureServiceHost.

Cause

WIF replaces the default ServiceAuthorizationManager with its own so that it can fully integrate with the WCF hosting environment. If you configure your ServiceAuthorizationManager before calling ConfigureServiceHost, WIF will replace the custom ServiceAuthorizationManager with WIF’s version.

Workaround

For more information, see WCF Application Compatibility.

ASP.NET RP Throws Exception When mapToWindows is True and useWindowsTokenService is False

Symptom

The following exception is thrown on an ASP.NET RP that is configured with a Saml11SecurityTokenHandler or Saml2SecurityTokenHandler, with MapToWindows set to true and the value of the UseWindowsTokenService attribute on the SamlSecurityTokenRequirement element set to false:

Server Error in '/ClaimsAwareWebApp' Application. 
________________________________________
Either a required impersonation level was not provided, or the provided impersonation level is invalid. (Exception from HRESULT: 0x80070542)

Workaround

Always set both MapToWindows and UseWindowsTokenService on the SamlSecurityTokenRequirement element to true.

HttpCookie Written by Windows Identity Foundation has Secure Property Set to False by Default

Symptom

HttpCookies written by WIF have their Secure property set to false by default. A Web site might have a login page that is protected by SSL, while the inner pages are not. If an HttpCookie is not secure, the client will send it with every request to the Web site, whether it is requesting a page that is protected by SSL or not. This allows other clients to intercept the cookie and use it to access other pages that are not protected by SSL.

Workaround

Always set the Secure property of HttpCookie to true. This ensures that the client only sends the cookie when it requests a page that is protected by SSL.

CreateChannelActingAs and CreateChannelOnBehalfOf Fail For Multiple Calls on the Same Channel

Symptoms

If you use a channel created with the CreateChannelActingAs or CreateChannelOnBehalfOf methods for multiple calls, WIF might throw an exception.

Workaround

There are three workarounds:

  1. Enable sessions to the back-end service.

  2. Create one channel per call.

  3. Use WSTrustChannel and CreateChannelWithIssuedToken.

Do Not Install WIF SDK on a Computer with Both .NET Framework 3.5 and .NET Framework 4 Installed

Symptoms

If you install the WIF SDK on a computer that has both the .NET Framework 3.5 and .NET Framework 4 installed, you might encounter the following:

  1. On Windows Server 2003, if the .NET Framework 3.5 version of the WIF SDK is installed, any samples that use ASP.NET fail with a RequestValidation error. This happens because Internet Information Services (IIS) uses the .NET Framework 4 version of the WIF SDK if the .NET Framework 4 is installed.

  2. On Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, if both the .NET Framework 3.5 and .NET Framework 4 versions of the WIF SDK are installed, and SamplePreReqSetup.bat is run for each version, only the samples from the version that was installed last will work.

    This is because SamplePreReqSetup.bat creates an application pool for use with the samples, and SamplePreReqSetup.bat for each version sets a different .NET Framework version on the pool. If you want to try the samples for both versions on the same computer, you must re-run SamplePreReqSetup.bat for the version whose samples you want to run.

  3. On Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, if both the .NET Framework 3.5 and .NET Framework 4 versions of the WIF SDK are installed, and you try to run the same sample for both versions to compare the results, setup.bat fails with the error “ERROR ( message:Failed to add duplicate collection element “/<application name>”. )” when run for the second sample.

    This is because the samples are identical for both versions, including the virtual directories and application names. If you want to try a sample for both versions on the same computer, after you run the first sample, you must run cleanup.bat to remove the virtual directory and application for the first sample before you run setup.bat for the second sample.

Workaround

Do not install the WIF SDK on a computer with both the .NET Framework 3.5 and .NET Framework 4 installed.