Replacing ASP.NET Forms Authentication with WIF Session Authentication (for the better)

Posted by Your DisplayName here! on Least Privilege See other posts from Least Privilege or by Your DisplayName here!
Published on Thu, 09 Feb 2012 21:14:54 GMT Indexed on 2012/03/18 18:20 UTC
Read the original article Hit count: 360

Filed under:

ASP.NET Forms Authentication and WIF Session Authentication (which has *nothing* to do with ASP.NET sessions) are very similar. Both inspect incoming requests for a special cookie that contains identity information, if that cookie is present it gets validated and if that is successful, the identity information is made available to the application via HttpContext.User/Thread.CurrentPrincipal.

The main difference between the two is the identity to cookie serialization engine that sits below. Whereas ForsmAuth can only store the name of the user and an additional UserData string. It is limited to a single cookie and hardcoded to protection via the machine key.

WIF session authentication in turn has these additional features:

  • Can serialize a complete ClaimsPrincipal (including claims) to the cookie(s).
  • Has a cookie overflow mechanism when data gets too big. In total it can create up to 8 cookies (á 4 KB) per domain (not that I would recommend round tripping that much data).
  • Supports server side caching (which is an extensible mechanism).
  • Has an extensible mechanism for protection (DPAPI by default, RSA as an option for web farms, and machine key based protection is coming in .NET 4.5)

So in other words – session authentication is the superior technology, and if done cleverly enough you can replace FormsAuth without any changes to your application code. The only features missing is the redirect mechanism to a login page and an easy to use API to set authentication cookies. But that’s easy to add ;)

FormsSessionAuthenticationModule
This module is a sub class of the standard WIF session module, adding the following features:

  • Handling EndRequest to do the redirect on 401s to the login page configured for FormsAuth.
  • Reads the FormsAuth cookie name, cookie domain, timeout and require SSL settings to configure the module accordingly.
  • Implements sliding expiration if configured for FormsAuth. It also uses the same algorithm as FormsAuth to calculate when the cookie needs renewal.
  • Implements caching of the principal on the server side (aka session mode) if configured in an AppSetting.
  • Supports claims transformation via a ClaimsAuthenticationManager.

As you can see, the whole module is designed to easily replace the FormsAuth mechanism. Simply set the authentication mode to None and register the module. In the spirit of the FormsAuthentication class, there is also now a SessionAuthentication class with the same methods and signatures (e.g. SetAuthCookie and SignOut). The rest of your application code should not be affected.

In addition the session module looks for a HttpContext item called “NoRedirect”. If that exists, the redirect to the login page will *not* happen, instead the 401 is passed back to the client. Very useful if you are implementing services or web APIs where you want the actual status code to be preserved. A corresponding UnauthorizedResult is provided that gives you easy access to the context item.

The download contains a sample app, the module and an inspector for session cookies and tokens. Let’s hope that in .NET 4.5 such a module comes out of the box.

HTH

© Least Privilege or respective owner

Related posts about IdentityModel