WIF SAML token POST and requestValidationMode=”2.0″

Just a quick note on the WIF SAML token POST and problems like this (you’ve probably had these problems too, if working with WIF and .NET 4.0):

System.Web.HttpRequestValidationException: 
A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo...").

(see e.g. Why am I getting the “A potentially dangerous Request.Form value was detected from the client” error?” on StackOverflow for an example of this).

There are numerous answers to this question, some good, and some not so good. Common to all of them, is that they either turn request validation off completely, by setting the <pages validateRequest="false"> attribute in web.config’s system.web section, or set request validation mode to 2.0 on the entire app.

There is, however, a more clever way. We only need to alter the requestValidationMode to 2.0 mode on the specific URL that WIF posts back the SAML token to. This can be done with a <location> element (see location Element (ASP.NET Settings Schema) for details) in your web.config, like this:

  <location path="WIFHandler">
    <system.web>
      <httpRuntime requestValidationMode="2.0" />
    </system.web>
  </location>

The “WIFHandler” location does not need to exist in your app, as WIF will shortcut the pipeline before ASP.NET tries to handle the request, and redirect you to the return url (ru in the wctx parameter of the SAML token POST) instead.

In your WIF configuration section of the web.config file, be sure to match the “reply” parameter with the location where you set request validation mode to 2.0 mode:

 <microsoft.identityModel>
    <service>
      <federatedAuthentication>
        <wsFederation passiveRedirectEnabled="true" issuer="https://localhost/STS/" realm="https://localhost/MyApp/" reply="https://localhost/MyApp/WIFHandler/" />

(...)
About these ads
This entry was posted in .NET, C#, WIF. Bookmark the permalink.

4 Responses to WIF SAML token POST and requestValidationMode=”2.0″

  1. Pingback: Unified Identity for Web Apps – the easy way | A Cloudy Place

  2. Pingback: Windows Azure and Cloud Computing Posts for 7/10/2012+ - Windows Azure Blog

  3. Bradley Cotier says:

    This is brilliant and solves my current problem perfectly. I am tasked with fronting customer websites with WIF but not to modify the website or overlap whatever authentication mechanism the site might have. I do this with a http module but was hitting the problem where .NET4 enforced request validation. Using your advice I now have a dummy endpoint where validation is switched off and, after custom WIF authentication, the browser is redirected to the original URL.

    Thanks

    Brad

  4. Fixed my issues immediately, thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s