Promising new WIF tools

Vittorio Bertocci has shared some exciting news about the upcoming WIF tools for Visual Studio 11 on his blog. The tools look really nice, especially the local development STS. Here are the direct links (for future reference):

• WIF Tools for Visual Studio 11 Part I: Using The Local Development STS
• WIF Tools for Visual Studio 11 Part II: Manipulating Common WIF Settings From the UI
• WIF Tools for Visual Studio 11 Part III: Connecting With a Business STS (e.g. ADFS2)
• WIF Tools for Visual Studio 11 Part IV: Get an F5 Experience with ACS2

On the blog, you'll also find that the Identity team is hiring. I just checked the list of open positions at Microsoft, and they have 35 (!) open positions on their identity page. I expect we'll see more cool stuff from the identity team in the future!

If you're a .NET developer, now is the time to get on the WIF train. WIF will be an integral part of the .NET framework as of version 4.5, which is currently in beta (for those of us who went all-in on WIF last year, this is quite a relief).

IIS 500 errors leave clues in the log

Yesterday I was playing around with the validateIntegratedModeConfiguration="true" setting on IIS 7.5. To my surprise I got an empty response back, with no indication of what went wrong.

Looking at the response with Fiddler yields:

HTTP/1.1 500 Internal Server Error
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 05 Mar 2012 15:59:52 GMT
Content-Length: 0

There's not much to work with here! I checked the event log, there was nothing there. So I started looking around for an error log of some sort (I used to play with Apache back in the days) turns out there's no such thing in IIS.

Some googling led me to an in-depth article: Troubleshoot IIS7 errors like a pro. I enabled detailed error messages for my website, still no luck.

Finally, I figured out that the easiest way to get an indication of what's going on is to check the IIS log. In the default setup, IIS keeps the logs for each website in: C:\inetpub\logs\LogFiles. Here's a log entry from my logfile (shortened for readability):

How to enable WIF token replay detection

Windows Identity Foundation (WIF) is vulnerable to replay of security tokens in its default configuration. The "Replay Detection" article on MSDN presents a good example of how things can go wrong without the replay detection (why do everyone have to use online banking as their example?):

As another example, suppose that a user opens a browser on a public kiosk, logs on to a bank account using the bank’s Web site, logs off and leaves, but does not close the browser. The response to the user’s logon page, which contains the STS token, is still in the browser’s history. Another person could then browse back to that response page and replay it, which would repost the STS token to the bank’s Web site.

This scenario is very much real and it does not involve any fancy hacking techniques. All you need is a browser and a "back" button. You'll find some scattered references on the Internet to the solution of the problem, the tokenReplayDetection configuration setting. You'll find a mention of the configuration element in the WIF FAQ on Technet and in the WIF book, but you'll find the most helpful explanation in the ACS security guidelines.

I'll cut to the chase, here's the config to enable the token replay detection. Please don't use the parameters as is, read the security considerations and tweak the values accordingly. Seriously.