Sliding Sessions for WIF 4.5

As it turns out, sliding sessions – sessions that are kept active by user’s activity, as opposed to sessions with a static expiration time – are quite a popular topic as of late.

I already covered the topic in details 3 years ago (time flies!!!) but of course at the time I wrote all of the sample code with WIF 3.5. I am inclined to say that not much changed in this department, you can pretty much use the same technique as long as you fix namespaces and class names here and there, but from the number of people that asked about this I am clearly underestimating the difficulty of the task.

So, how about the following: if you are interested in learning how to do this head to that old post and read through the theory, so that I won’t have to re-write it here; I’ll be waiting here, and once you’re back I’ll show you the code that will work with .NET 4.5. Deal?

[…]

Welcome back!

Let’s add sliding sessions to one typical WIF-based app, MVC or WebForm will both work. Here there are the steps:

• Add references to System.identityModel.dll and Sistem.identityModel.Services.dll
• Open global.asax.cs. Add the following usings:

using System.IdentityModel.Services;
using System.IdentityModel.Tokens;

• next, add the method below. Note, I am assuming you kept the default names for the WIF Http modules in config

void SessionAuthenticationModule_SessionSecurityTokenReceived(object sender,

                System.IdentityModel.Services.SessionSecurityTokenReceivedEventArgs e)
{ 
    DateTime now = DateTime.UtcNow;
    SessionSecurityToken sst = e.SessionToken;
    DateTime validFrom = sst.ValidFrom;
    DateTime validTo = sst.ValidTo; 
    if ((now < validTo) && (now > validFrom.AddMinutes( (validTo.Minute - validFrom.Minute) / 2)) ) 
    { 
        SessionAuthenticationModule sam = sender as SessionAuthenticationModule;
        e.SessionToken = sam.CreateSessionSecurityToken(sst.ClaimsPrincipal,

                                                        sst.Context,

                                                        now,

                                                        now.AddMinutes(2),

                                                        sst.IsPersistent); 
        e.ReissueCookie = true; 
    }
}

I already explained the code in the old post, hence I won’t go through that again here.
Rather, I’ll just add a couple of headsup that might save you some time when you’ll test the feature:

• WIF has a default clockskew of 5 minutes: that’s a tolerance which accounts for possible differences in the clock of the machine where your app runs and the machine that issued the authentication token. Given that the code sample above mints cookies that are valid for just two minutes, that’s kind of hard to test if the code really works one possible trick is to temporarily put the clockskew to zero. That’s very straightforward, you just need to use the maximumclockskew attribute value to zero in the identityConfiguration element

 <identityConfiguration maximumClockSkew="0">

• If you are testing this against an STS that does save session cookies of their own, and the STS cookies outlive the ones in your RP, invalidating the RP’s cookie would not make much difference: you’d just be redirected to the STS, where you are already authenticated, and you’d silently obtain a new token for the RP. If that’s your setup, you might consider triggering a full fledged signout. Anyway, for testing purposes here there’s what I did: once signed in the RP I opened another tab in the same browser instance, navigated to the IdP, opened the browser’s developer tool and cleaned up the cookies for the IdP’s domain. Then I waited 3 minutes, and sure enough when I tried to access a different route on the RP I got the familiar STS prompt instead

Well, that’s it. I hope this will be useful; if this matter taught me something, it’s that I have a blind spot for what things are difficult in the migration process between WIF versions. In fact, if there are areas where you find that the migration from WIF 3.5 to .NET 4.5 is less than straightforward, please let us know and we’ll see what we can do to help!