This topic discusses known issues in the Windows® Identity Foundation (WIF) together with existing workarounds.
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.
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.
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>
|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.|
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 '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.
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.
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.
If you have already implemented a CustomAuthorizationManager then it will no longer work once you enable WIF using ConfigureServiceHost.
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.
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)
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.
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.
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:
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
RequestValidationerror. This happens because Internet Information Services (IIS) uses the .NET Framework 4 version of the WIF SDK if the .NET Framework 4 is installed.
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.
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.
Do not install the WIF SDK on a computer with both the .NET Framework 3.5 and .NET Framework 4 installed.