As you know, development stacks implementing web sign in protocols traditionally handle sessions by tracking the content of the initial token in form of a session cookie. That is not the only way in which it could be done, and I do think it will change in the future, but for the time being that’s the mainstream technique.

Tokens can sometimes get quite big, especially when you add multi value claims to them (groups, roles). At the same time, the total allowance per domain can be quite restrictive: for example, Safari won’t send more than 4K of cookies per domain.

WIF had a mechanism for helping to deal with big cookies, the IsReferenceMode (IsSessionMode in WIF1.0) flag which allowed you to use the cookie to persist a session identifier and maintain the actual content of the session server side. I described the technique here (four years ago!!! Where did that time go?).

Given the importance of the scenario, we wanted to ensure that the functionality is available also in the new OWIN middleware for WS-Federation and OpenId Connect – and in fact for any module that needs it.
Chris and Brent mulled over the problem a bit, then came out with an elegant solution to the problem. The cookie middleware now features a pluggable store interface, that you can use for customizing how an AuthenticationTicket is preserved across calls. If you want to provide an alternative store for your authentication tickets, all you need to do is implementing that interface and passing an instance to the cookie middleware at initialization time.

Here there’s the interface:

public interface IAuthenticationSessionStore
    Task RemoveAsync(string key);
    Task RenewAsync(string key, AuthenticationTicket ticket);
    Task<AuthenticationTicket> RetrieveAsync(string key);
    Task<string> StoreAsync(AuthenticationTicket ticket);

Pretty straightforward, right? Upon first receiving a valid token, the pipeline hands you the corresponding AuthenticationTicket in StoreAsync: you can decide which key to use for identifying it (as long as it is a string) and how/where to save the AuthenticaticationTicket bits. The cookie middleware will take care of saving the key in the session cookie, and hand it over to you via RetrieveAsync the next time it sees the session cookie again.

To give you an idea of how to take advantage of this feature, under the watchful eyes of Brent and Chris I wrote a naïve IAuthenticationSessionStore implementation based on the Entity Framework. You can find the corresponding GIST here. It is very straightforward, hence I left it comment-free Smile
Using it is very simple, you just pass a new store instance to the cookie middleware initialization routine.

IDataProtector dataProtector = app.CreateDataProtector(typeof(NaiveEFAuthSessionStore).FullName, "MyEntropy", "v1");
    new CookieAuthenticationOptions() 
       SessionStore = new NaiveEFAuthSessionStore(new TicketDataFormat(dataProtector)) 

    new WsFederationAuthenticationOptions
        Wtrealm = realm,
        MetadataAddress = metadata                                      

The data protector parameter is just an artifact of this implementation and how it protects the AuthenticationTicket in the db – you can use anything that fits your scenario.

Note, in order to use this feature you need to use the NuGets from the nightly builds – you can use the feed in For example, for the sample code above I used the package Microsoft.Owin.Security.Cookies version 3.0.0-beta2-30508-029-dev.

We Need Feedback!

This is where you come into play. This is a super important feature, and one that has multiple moving parts. We really need as much real world validation as we can get.  If you can give it a spin and let us know if that works for you, that would be fantastic!

Feel free to hit me though this contact form, to come to find me in person if you are coming to TechEd, or hang out at the OWIN Jabbr… the more feedback we get, the sooner we’ll ship Winking smile

Thanks in advance!!!


Leave a Reply

Your email address will not be published. Required fields are marked *