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

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 ;)

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.


This entry was posted in ASP.NET, IdentityModel. Bookmark the permalink.

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

  1. Darren says:

    Hi, great stuff. Unfortunately the download link is broken. Cheers.

  2. Darren says:

    Forget that. I just found it on your skydrive. Thanks

  3. Art says:

    Skydrive doesn’t work either

  4. Jose Luis says:

    How we can use the userdata stored in the cookie to use by the knockout.js viewmodels in the client?

  5. Provide a web api endpoint that returns the contents of the claims collection – then you can bind that data to your UI.

  6. Pingback: Replacing forms authentication with WIF’s session authentication module (SAM) to enable claims aware identity « brockallen

  7. RonyK says:

    Nice! Is there a reason why this module is not used in thinktecture’s IdentityServer ?

    • RonyK says:

      So I must be missing something. For this module to be used instead of the “System.IdentityModel.Services.SessionAuthenticationModule” shouldn’t the IdentityServer website add it in the “modules” section in its web.config, instead of the “System.IdentityModel.Services.SessionAuthenticationModule” ?
      Or is integrated into IdSrv some other way?

  8. Ah I see – well – the purpose of the FormsSessionAuthenticationModule was to provide a drop-in replacement for the FormsAuthenticationModule. It is not really needed when you build something from scratch – like IdSrv.

  9. KARTHIKEYAN N R says:

    sam.WriteSessionTokenToCookie(token) throws null exception error. please help.. this is my code:

    Dim claims = LoadClaimsForUser(UserName)
    Dim identity = New ClaimsIdentity(claims, “Forms”)
    Dim claimsPrincipal = New ClaimsPrincipal(identity)
    Dim token = New SessionSecurityToken(claimsPrincipal)
    Dim sam = FederatedAuthentication.SessionAuthenticationModule

  10. KARTHIKEYAN N R says:

    and also under config section i added the following

    but the System.NullReferenceException error occured in sam.WriteSessionTokenToCookie(token). pl help

    • KARTHIKEYAN N R says:

      My web.config is : modules
      add name=”SessionAuthenticationModule”
      type=”System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089″

      • KARTHIKEYAN N R says:

        Finally I got it… Thank u Dominick…. I did mistake in IENUMERABLE object.. now i got cleared… I cant be successful without this excellent article….. thanks again…..

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s