Use WIF bootstrapped tokens or Azure ACS? Read this

Posted on 12/13/2011 @ 10:31 AM in #Vanilla .NET by | Feedback | 998 views

Okay so there is an interesting limitation one should be aware of when working with bootstrapped tokens and Azure ACS.

As you know, WIF uses FedAuth cookies. FedAuth cookies as Vittorio demonstrates in this blog post, are usually small, but can get fairly big when you start putting in Base64 binaries in, or especially if you use bootstrapped cookies.

Azure ACS must use bootstrapped cookies! So your FedAuth cookies are huge! As an example, with two claims, the cookie is 5KB, way over the 4KB cookie limit per domain of Safari and Opera. Wait, this means, you effectively can’t use Azure ACS with Safari and Opera.

Opera – well that’s a personal choice browser, but Safari effectively locks out all iOS devices. Damn! Are you telling me you can’t effectively use Azure ACS with iOS? Hmm ..

Well there are some workarounds,

1. You can set FederatedAuthentication.SessionAuthenticationModule.IsSessionMode = true in the global.asax of your web application as shown below,

   1:  <%@ Import Namespace="Microsoft.IdentityModel.Web" %>
   3:  <script runat="server">
   5:        void WSFederationAuthenticationModule_SessionSecurityTokenCreated(object sender, Microsoft.IdentityModel.Web.SessionSecurityTokenCreatedEventArgs e)
   6:      {
   7:          FederatedAuthentication.SessionAuthenticationModule.IsSessionMode = true;
   8:      }


  • This approach won’t work for SharePoint since you cannot override SharePoint’s global.asax, but you can achieve the safe effect using a static class that is hit by an HttpModule instead.
  • This approach is not Azure ready, since Azure does not allow in process session state.
  • This approach will not work for NLB environments.

2. You can use the above mechanism in combination with a custom SecurityTokenCache. You can find a good description of this technique in this PDC session, and an Azure ready security token cache at

  • This will work with SharePoint but requires web.config tweaks, and the SecurityTokenCache implementation will probably need to back Windows Server AppFabric. I’ll write one when I have a chance, but you can find the general technique described in this article I wrote a while ago for ASP.NET session state.

3. You can just avoid all the above, and implement authentication purely using OAuthv2. To implement OAuthv2, you’ll have to write a custom service and deploy that into SharePoint (or Azure for that matter). This is trivial compared to the above two alternatives, and works nicely.

Sound off but keep it civil:

Older comments..

On 12/13/2011 10:36:48 AM Steve Syfuhs said ..
Technically that chunk of code won't work regardless of the application. SessionSecurityTokenCreated doesn't fire at the right time. You need to stick that code in SecurityTokenValidated:

On 12/13/2011 10:41:29 AM Sahil Malik said ..
Thanks for your comment Steve. Good point.

I'm curious, how did you discover this blogpost in literally 30 seconds after I posted it? :)