SP cookie bloat

[Paul Henson]

I'm investigating an issue where sometimes clients trying to access a 
shibboleth SP protected service receive a 400 Bad Request error because 
the size of the request headers is too big. When this occurs, there are 
an excessive number of _opensaml_req_ss cookies causing the problem.

For a single login, the initial connection resulting in a redirect to 
the idp sets a cookie:

GET https://sp-dev.pbhware.com/shibtest/ HTTP/1.1
HTTP/1.1 302 Found
Set-Cookie: 
_opensaml_req_ss%3Amem%3A42e08ffb8f67278dac7258fd5f4579e45a4075b7fdf24437c1653ec0067e2d87=_0d0cc6902f7c55fe70fae0eb7ac5b503; 
path=/; secure; HttpOnly; SameSite=None

and once the authentication is complete and processed by the SP, the 
cookie is cleared:

POST https://sp-dev.pbhware.com/Shibboleth.sso/SAML2/POST HTTP/1.1
Cookie: 
_opensaml_req_ss%3Amem%3A42e08ffb8f67278dac7258fd5f4579e45a4075b7fdf24437c1653ec0067e2d87=_0d0cc6902f7c55fe70fae0eb7ac5b503

HTTP/1.1 302 Found
Set-Cookie: 
_opensaml_req_ss%3Amem%3A42e08ffb8f67278dac7258fd5f4579e45a4075b7fdf24437c1653ec0067e2d87=; 
expires=Mon, 01 Jan 2001 00:00:00 GMT; path=/; secure; HttpOnly; 
SameSite=None


However, if you don't complete the session, the cookies pile up. The 
default configuration of the SP starts clearing cookies once the count 
hits 21:

Cookie: 
_opensaml_req_ss%3Amem%3Ab9d2462a0a29a95adf2eb12ecfc44e09c36f371b93bd20ad3a8e1d940af2a689=_d623fb227342b82533956d54782bf4f5; 
_opensaml_req_ss%3Amem%3Af33ecbdc05fdadd0b25562077229b7b26a7d1d114f3f4e31d66f2f1b1edf88aa=_5e7f061f7db6363e2bb2dc933c1a6fda; 
_opensaml_req_ss%3Amem%3Aafe95479b2720b3701b06e716e626b7b699373b2df18b779e1afef92e8ab562e=_85ae28403e4daca15a0a1db34f3348b6; 
_opensaml_req_ss%3Amem%3Af638853f9ef3c92c8a3e894a069026491a4b6fb547d98abac78c07d7157085e7=_71b05ec8ab9c8c72e23d22446ef25e0e; 
_opensaml_req_ss%3Amem%3Ae876a16aef5737369d1f6e059540feb931fbd4dc3203bf63059be2d7a899fef6=_3667db9278e3197a6e44a2e589a0bac9; 
_opensaml_req_ss%3Amem%3Aee52d99fa8aaaf17e20679bb74994ea5d0de45393ab794aa22177c4db11e604c=_b1ea6e860e8a154a46d1f564a1584333; 
_opensaml_req_ss%3Amem%3Ab1baca5c249597c096643ccc8027aa937b07aa3550b3ea3dfbef90d7ac520f40=_3bedd7378a6a2e2f83c79a1579cec65b; 
_opensaml_req_ss%3Amem%3Ac46cbafb1d28f5f9030ef8081d8cd5a1d210f00372eb86def1ab6bf207fcee96=_a8b89debde476efb024fd4c8f106bbb3; 
_opensaml_req_ss%3Amem%3Acb7dd1e848a8534653138b103c4964038aa7764d41b3b84c2d13ca2685499fdf=_8f20f251c6f758c294441f029807af44; 
_opensaml_req_ss%3Amem%3Ac06330aa0e58c5c56fac09df236a6e2b917ecc134b04c5d114353d3303f544f1=_b1f6b3946860b721a7e7645ed7282f8a; 
_opensaml_req_ss%3Amem%3Af42f17f4727c7ee43446846e33c674c1405fd81d42f550794d5d23c7fe98a5e1=_6bc8349828a1209f6cf9ab83b98438a8; 
_opensaml_req_ss%3Amem%3Aa95e5809aa59e67f00bf83defce9d27bdb39cf7ea236d17d4b32967840f1b694=_be277c010557138517bb1b35cbe07a13; 
_opensaml_req_ss%3Amem%3Ac26e6331156f335fb9c3963bc76517cffd26ae6fdbb1cc84c43560caa3603d00=_d022858b65bb9949a6f3235f05243e8b; 
_opensaml_req_ss%3Amem%3Ab8d28906a4ac88153f0d0e820c3ebd3e43662cbf092edd157d12add11c23566f=_068fc962116b1a76711a70741aabff85; 
_opensaml_req_ss%3Amem%3Aaf405c2b3405a892240a5f20303e8d9a233084420a19590ca1e69bb764bf9c1c=_db6913f47adad3f41080ef3837d6b076; 
_opensaml_req_ss%3Amem%3Ae7b2663628e02b0bff6b3be62f78561f0d03cfef13201d03bc8871f6f1ef6003=_f6993d27edbc61cb621d07e60f9ec84d; 
_opensaml_req_ss%3Amem%3Ad7097f70ea5fc0abd19f04f2faed492905d3b295249fca154b07bd983590758a=_644ae8685669b20065529fc53c9e3ead; 
_opensaml_req_ss%3Amem%3Afc81ed71473ee047fa5e713e691ee3c97ea9da5fd2c0a1d2e4d00622202523fe=_15bdb029bfbb55e5f539bb795b6d4c2c; 
_opensaml_req_ss%3Amem%3Aca2b202a3d4ec11ecc72044df6997f8674353429caf6fc0c3faa108af8ed4640=_9a0cdacdf18c264a243011006e4b4637; 
_opensaml_req_ss%3Amem%3Acf0471bb9f6c2ff414d4d9f8c8b4373f57aa3b0d906d9eae7bcd49ffd4d73268=_fe1f5b8c8313de4e22429533dae75c97; 
_opensaml_req_ss%3Amem%3A2c7a0154bf6fd59739981e8a5aa3ca3bf7e9fc7e8c10ea6ec28154db8b2a3139=_676098b86777448e6c14dffc669bc046


Set-Cookie: 
_opensaml_req_ss%3Amem%3A2c7a0154bf6fd59739981e8a5aa3ca3bf7e9fc7e8c10ea6ec28154db8b2a3139=; 
expires=Mon, 01 Jan 2001 00:00:00 GMT; path=/; secure; HttpOnly; 
SameSite=None
_opensaml_req_ss%3Amem%3Ab6687ca42a98b66033fb55c2fee767931c9bd7ad1ce0836842641f333e9fe2b6=_25b374cbecff5b3b20e1e1e25f9ab819; 
path=/; secure; HttpOnly; SameSite=None


It removes any cookies beyond 20 and adds a new one. However, while this 
works fine for sequential access, it fails in the case of parallel 
access. If a web browser loads in parallel dozens of resources with no 
SP state (say when an application session times out), all of which 
create a new opensaml session, the cookie count can easily exceed 21 and 
reach a point where there are so many the requests start to fail. All of 
the parallel requests remove the same cookie(s) but add a new distinct 
one, so say 20 requests could remove one cookie but add 20. In the 
particular scenario I am investigating they have the same site cookie 
workaround enabled which also doubles the number of cookies in play 8-/.

This is in one way a browser/application issue, but in another an issue 
with the SP. Assuming you cannot change the browser and application 
behavior, how can the SP prevent this from happening?

Generally cookies are presented in creation time order, so the current 
implementation results in the oldest cookies being saved and the newest 
cookies being purged? Purging the older cookies seems like it would make 
more sense, but would have the same issue for parallel requests in that 
all of the requests would purge the same cookies. What if the selection 
of which cookies to purge was made randomly, such that parallel requests 
would probabilistically purge different cookies and reduce the chance of 
cookie bloat in the situation?


-- 
Signet - The Art of Access
https://www.signet.id/