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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Post Navigation