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.

  Copy Code
<%@ Page ValidateRequest="false"%>

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

  Copy Code
<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:

  Copy Code
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 'http://localhost:8008/RP/mex' using WS-Metadata Exchange or DISCO.
Error: Obtaining metadata from issuer 'http://localhost:8000/Sts/mex' failed with error 'System.InvalidOperationException: Metadata contains a reference that cannot be resolved: 'http://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:

  Copy Code
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.