Questions about the cookies used with WIF


  • I'm using the WIF Extension for SAML 2.0 and recently ran into an issue related to the cookies generated during the SSO process.  When a user authenticates the application it generates several cookies, for example:

      • FedId
      • FedAuth
      • FedAuth1
      • [fourth cookie name is a GUID, changes for each SSO]

    That last cookie with the GUID has grown extremely large over a period  of time and I'm not sure why it is, and what if anything I am able to do to manage it's size.  If I decode that cookie value it just seems to be counter starting at 0, for example:

    0;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;…. 3110;3111;3112;3113;3114;3115;3116;3117;3118;3119;3120;3121;3122;3123

    Currently it appears that the GUID cookie gets broken up into upwards of 20 chunks at approximately 4k a piece.  This is generating 400 errors for the clients as the header size is too large for IIS to handle.  Has anyone else run into this issue, or know of a way to limit the size of this cookie so that it doesn't reach a size so large?

    Thursday, September 6, 2012 6:48 PM

All replies

  • My organization is experiencing this same issue.  Have you found a resolution yet?
    Friday, October 5, 2012 3:39 PM
  • Hello - my organisation is also experiencing this same issue and it is causing 400 errors for users after a few page clicks.  Has anyone resolved this issue?  Any help much appreciated.
    Monday, October 15, 2012 10:00 AM
  • Here are some resolutions to the issue which we implemented and I hope may help others:

    1) First immediate quick fix is to recycle the app pool more frequently on the webserver. Each time the app pool recycles the cookie restarts at zero length. This gives you some breathing space and will prevent the cookie pushing you over the 16K header limit. Bear in mind that each successive user logging on to the server will add an additional integer to the cookie, so in order to work out how frequently to recycle the app pool, you need an estimate of how many users log on to your website in a given time interval at peak load and hence how quickly you need to recycle the app pool. Depending on what else you send in the headers and what other cookies you have, you will probably need to be recycling before 3,000 users have logged in since the last recycle. If you are in a webfarm set-up then the load will be spread (as the cookie increments separately on each webserver) and you can recycle more slowly.

    2) If the app pool recycle period is too frequent to be acceptable, then you can increase the maximum permitted header size on the webserver. This will enable the webserver to accept headers over 16K. To do this in IIS7 you need a registry hack as described here and a full server re-boot. The registry change to increase this to 32K for example is:

    The MaxRequestByes and MaxFieldLength registry keys will need to be added and set with a value higher than the default of 16384 to allow for increased size in header request.

    1. Open registry editor, such as Regedit.exe or Regedt32.exe

    2. Navigate to: HKLM\System\CurrentControlSet\Services\HTTP\Parameters

    3. Right-click Parameters, select New | DWORD value, and then name the value

    4. Right-click Parameters, select New | DWORD value, and then name the value

    5. In the right pane, double-click MaxFieldLength, and then set its value to 32768

    6. In the right pane, double-click MaxRequestBytes, and then set its value to 32768

    7. Close the registry editor and re-boot the server for the changes to take effect

    3) Once the IIS app pool recycle is in place you have some breathing space to dev and QA a longer term fix. In our case we ended up modifying some of the WIF libraries and the saml2authenticationModule to use boundcache and prevent SessionParticipantStorage from using CookieBasedStringStorage. Altenratively you can pass nulls as the last two parameters to the AssertionConsumerService to set up the SessionParticipantStorage as null. As far as we've found there isn't an 'out of the box solution', but after a few days with 'reflector' and rewriting bits of WIF it seems to work (not an ideal outcome but at least stability is restored).

    4) Finally show your dev team the cookie and the issue as an example of some bad coding practice. It must be a microsoft bug for sure - but until they fix it, it's an excellent tutorial on how not to code, the sort of implementations that should be picked up by peer review (by which I mean MSoft should have picked it up at peer review), how you should do bounds checking, why you must performance test (soak testing and load testing), how easy it is to be exposed to DOS and why you can't automatically trust 3rd party libraries!

    • Proposed as answer by nick gibbs Friday, October 19, 2012 1:50 PM
    Friday, October 19, 2012 1:49 PM
  • Although I voted on your reply, the "final" solution (step 3 from ur reply) we made here was different and solved the problem with a clean way.

    I wrote about it here: http://blog.brunogarcia.com/2012/12/pitfalls-on-wifsaml2-and-selenium.html

    Also, I believe the biggest point from your reply is the step 4:

    "...and why you can't automatically trust 3rd party libraries" :)

    Bruno Garcia MCPD Web 4, 3.5, 2.0 - MCSA Windows Server 2003

    Monday, February 11, 2013 5:13 PM