Thursday, 20 December 2012
This is a quick post today that might save folks the same trouble I had to go through when upgrading my Windows Identity Foundation (WIF) enabled MVC website to the latest version of .NET. The scenario is that you might want to enrich the claims coming from your STS with additional claims of your choosing. To do this, there is a common technique of creating a class the derives from ClaimsAuthenticationManager and overrides the Authenticate method. Consider this sample ClaimsAuthenticationManager:
The issue we have is that we need to provide an implementation of ITenantRepository here in order to lookup the data for the additional claims we are adding. If you are lucky enough to find the article on MSDN, it will show you how to wire in a custom ClaimsAuthenticationManager using the web.config. I don't want to hardcode references to an implementation of my TenantRepository, so using config is not a great option for me.
In the older WIF model (Microsoft.IdentityModel) for .NET <= 4.0, you hooked the ServiceConfigurationCreated event:
But, in .NET 4.5, all of the namespaces and a lot of the classes are updated (System.IdentityModel). It took me a long time in Reflector to figure out how to hook the configuration being created again. Turns out you need to reference System.IdentityModel.Services and find the FederatedAuthentication class. Here you go:
Thursday, 14 July 2011
I was working on a Windows Azure website solution the other day and suddenly started getting this error when I tried to run the site with a debugger:
This error is one of the hardest to diagnose. Typically, it means that there is something crashing in your website before the debugger can attach. A good candidate to check is your global.asax to see if you have changed anything there. I knew that the global.asax had not been changed, so it was puzzling. Naturally, I took the normal course of action:
- Run the website without debug inside the emulator.
- Run the website with and without debugging outside the emulator.
- Tried it on another machine
None of these methods gave me any clue what the issue was as they all worked perfectly fine. It was killing me that it only happened on debugging inside the emulator and only on 1 machine (the one I really wanted to work). I was desperately looking for a solution that did not involve rebuilding the machine. I turned on SysInternal's DebugView to see if there were some debug messages telling me what the message was. I saw an interesting number of things, but nothing that really stood out as the source of the error. However, I did notice the process ID of what appeared to be reporting errors:
Looking at Process Explorer, I found this was for DFAgent.exe (the Dev Fabric Agent). I could see that it was starting with an environment variable, so I took a look at where that was happening:
That gave me a direction to start looking. I opened the %UserProfile%\AppData\Local\Temp directory and found a conveniently named file there called Visual Studio Web Debugger.log.
A quick look at it showed it to be HTML, so one rename later and viola!
One of our developers had overridden the <httpErrors> setting in web.config that was disallowed on my 1 machine. I opened my applicationHost.config using a Administatrive Notepad and sure enough:
So, the moral of the story is next time, just take a look at this log file and you might find the issue. I suspect the reason that this only happened on debug and not when running without the debugger was that for some reason the debugger is looking for a file called debugattach.aspx. Since this file does not exist on my machine, it throws a 404, which in turn tries to access the <httpErrors> setting, which culminates in the 500.19 server error. I hope this saves someone the many hours I spent finding it and I hope it prevents you from rebuilding your machine as I almost did.