One possible cause of accumulating __shibstate_xxx cookies

[Jon Warbrick]

We've recently managed to understand one circumstance in which 
__shibstate_xxx cookies can end up accumulating to the point where the 
Cookie: header gets long enough that web servers start rejecting it. I'm 
documenting it here in case the information helps anyone else.

Each __shibstate_xxx cookie has a unique name. They are set before redirecting 
the user's browser in the direction of an IdP, and actively deleted once 
authentication completes.

We have 'shibbolised' a copy of Plone. While editing the content of a page, a 
fragment of JavaScript on the edit page fetches a URL on the Plone server every 
5 minutes, acting as a heartbeat indicating that the page is still being edited 
and allowing anyone else who tries to edit it to be warned.

While the user's authentication sessions on the Plone SP and/or the 
corresponding IdP remain valid this works fine. However once they expire (for 
example if someone leaves an editing page open overnight) authentication 
exchanges starts to be triggered which will never complete. Each one sets a new 
__shibstate_xxx cookie which is never deleted. Eventually there are too many 
and the server starts rejecting further requests. Quiting the browser at this 
point is the easiest work around.

It's possible to avoid the problem by removing the relayState attribute from 
the relevant <SessionInitiator> element in the SP config. This causes the relay 
state (the 'return URL') to do a round trip via the IdP - the resulting privacy 
leak isn't significant in our case. An alternative would be to store relay 
state in SP persistent storage, though given long enough this might exchange a 
Cookie header length overflow with exhausting the memory or disk space on the 
SP! A further application-specific possibility is to fix the JavaScript code to 
give up if the attempt to access the resource starts to fail or to be met with 
redirects.

Jon.

-- 
Jon Warbrick
Web/News Development, Computing Service, University of Cambridge