One other situation I recently came across was regarding WIF and the pipeline security applied to it. Basically, due to up-scaling a project from one server (I know…) to multiple-instances, the app kept going into infinite redirect loops (HTTP 302), thus not allowing users to wander around the app. The case like this:

1. The user first visits the page

2. The user clicks anything in the page

3. The app goes into infinite 302.

The situation was cause by the security mechanisms the make the ASP.NET session authentication secure. Basically, by default, the DPAPI security providers are used. This basically states that for every single new session, a random key is generated that the user can wander around. That key is normally kept in the session providers, but is related to the keys used by the machine. Obviously, in a webfarm scenario (such as a multi-instance cloud service), DPAPI is useless and causes a CryptographicException to be thrown, since the FedAuth cookie gets encrypted by one machine and when you redo a request to your app, the cookie can no longer we decrypted.

If, for any case, you have a custom error page and if you, like in my case, must have the security mechanisms inside a Master page and mostly if the Error page inherits the Master page, you will, like me, get an infinite redirect loop (302).

The solution to this is to configure (using the web.config file) your IIS machines to use another security pipeline mechanism, such as MachineKey encryption. Moreover, it is obviously required to configure a static machine key and validation key, yet most Google-related results for this situation fail to remember that such a setting is required. Otherwise, the different machines in the web farm still get different keys and the FedAuth cookie won’t decrypted, failing in the CryptographicException all over again.

The required configuration for web.config for replacing your DPAPI security mechanisms with MachineKey cryptography is:

<securityTokenHandlers>

<add type=”System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />

<remove type=”System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />

</securityTokenHandlers>

As for the machine key, you have to choose an appropiate key size (only HEXA-DEC chars), as mentioned on this MSDN article on machinekey configuration in ASP.NET 2.0 (I know it’s old, but it’s still valid for ASP.NET 4.0).

Choose an appropriate key size. The recommended key lengths are as follows:

  • For SHA1, set the validationKey to 64 bytes (128 hexadecimal characters).
  • For AES, set the decryptionKey to 32 bytes (64 hexadecimal characters).
  • For 3DES, set the decryptionKey to 24 bytes (48 hexadecimal characters).

A.

After attending last year’s ITCamp oganized in Cluj-Napoca, Romania, I was definite that I would attend this year again, even though I will have to leave for Cluj-Napoca on my b-day party (which I absolutely hate, because in the last 6 years, faith made it like that the my b-day would always find in a foreign city or country).

Anyway, back to ITCamp 2013. ITCamp is a developer and sysadmin conference where Microsoft technologies (and related to Microsoft technologies – such as Linux :) ) are presented by industry experts (technology gurus, MVPs, Microsoft Evangelists, ex-Microsoft employees, technology enthusiasts etc.). On their agenda you will find things like ‘Building Elastic, Autoscalable Solutions with Windows Azure‘, ‘Developing for Windows 8 with F# and WebSharper‘, ‘MVC – Common pitfalls and how to resolve them‘, ‘Transact-SQL from 0 to SQL Server 2012‘, ‘Kinect for Windows – Designing Software for Gesture & Voice Controlled User Interfaces‘ and so many other cool things you might actually be interested in!

Last but definitely not least, Richard Campbell and Tim Huckaby are also among the speakers!

Do google ITCamp or go straight to http://itcamp.ro, check the agenda out and register asap: seats are already filling up :)

Alex

I just had this scenario, when I would add whatever action control on a page and set its PostBackUrl property to another page. I would do this because I wanted to send some data from the current page (more like a view, where you input stuff) to another page via the POST method. However, for some super perculiar reason, I kept missing something, because whenever I would hit the control that did the POST action via the PostBackUrl property setting, the Request.RequestType that was incomming to the destination page was GET instead. Obviously, the Request.Form property didn’t containt any collections from which to extract the expected data from. After loosing precious time around this matter, I just realized that the ASP.NET WebForm template I was building the project upon had the preview of the FriendlyUrls NuGet package installed. What is FriendlyUrls? Basically, it’s a Microsoft signed NuGet package that handles your website in such a manner that your URLs become friendly: e.g. http://localhost/Default.aspx can also be visited through http://localhost/Default (which apparently is friendly). Don’t get me wrong, it’s not that FriendlyUrls has something against Posting via PostBackUrl property. It’s just that the template I was building the project upon had the 1.0.0-alpha1 version of FriendlyUrls installed rather than a final release of the package. After updating the package to its final release, I was able to POST via forms using the PostBackUrl property just fine. Hope this helps other outside there! A.