[Shib-Users] Shibboleth Cookie Accumulation

[Dennis Roberts]

I recently encountered a 413 HTTP error, which occurred because someone had Firefox configured to remember which tabs were open and always closed the browser instead of explicitly logging out of the application. This appears to have happened because the Shibboleth service provider assigns unique names to Shibboleth cookies and these cookies are never cleared out. For the time being, I recommended always explicitly logging out of the application, but I imagine that other people may run into this problem.

Is there a way to configure the SP to look for cookies that it previously set and clear them? I can imagine cases in which this shouldn't be done (for example when there are multiple SPs in the same domain), but I don't see any reason not to do it in this case. I could be missing something, though.

Thanks,
Dennis



--
Subscription settings: http://groups.google.com/group/shibboleth-users/subscribe?hl=en

[Scott Cantor]

> I recently encountered a 413 HTTP error, which occurred because someone
had
> Firefox configured to remember which tabs were open and always closed the
> browser instead of explicitly logging out of the application. This
appears
> to have happened because the Shibboleth service provider assigns unique
> names to Shibboleth cookies and these cookies are never cleared out.

That's not the case, they're cleared out in the normal fashion in most
scenarios, and none of them are persistent (well, none but one that's beside
the point here). The fact that the session restore behavior prevents them
from being disposed of is not something I can fix.

> For the time being, I recommended always explicitly logging out of the
> application, but I imagine that other people may run into this problem.

Logging out should have no affect on this, particular since that would clear
the cookies in the same way, and because there are cookies generated both
before and after login.

> Is there a way to configure the SP to look for cookies that it
> previously set and clear them? I can imagine cases in which this
> shouldn't be done (for example when there are multiple SPs in the same
> domain), but I don't see any reason not to do it in this case. I could
> be missing something, though.

The only way to clear a cookie is to set one with an expiration in the past.
That's what it does.

It may be the case that using javascript directly to affect the cookie store
has different behavior, but if that were the "solution", I'd have to
generate something with Javascript in it, and right now all of the normal
flows in the SP are redirects.

-- Scott

[Scott Cantor]

For clarification, there are orphaning scenarios such as accessing an SP and
then never returning to it. That leaves a state cookie in place for the
session. That's the only cookie that isn't just recycled. The authentication
session cookies all have fixed per-SP/app names, not random ones, so one
login just overwrites the previous one.

-- Scott

[Robert Basch]

On Apr 8, 2010, at 5:45 PM, Dennis Roberts wrote:

> I recently encountered a 413 HTTP error, which occurred because
> someone had Firefox configured to remember which tabs were open and
> always closed the browser instead of explicitly logging out of the
> application. This appears to have happened because the Shibboleth
> service provider assigns unique names to Shibboleth cookies and
> these cookies are never cleared out.

We heard reports of users running into this occasionally, with shibstate
cookies accumulating in saved Firefox sessions. When we looked into it,
we found that Firefox would only restore non-secure session cookies, and
the relevant SP was not setting its cookies to be secure. So setting
the
cookies to be secure (via the cookieProps property in <Sessions>), which
is advisable anyway, might resolve this for you. (In our SP's case,
they
could not do this without introducing loops, as they do not force SSL-
only
access, so for now I think they just tell users to clear their cookies
when such a problem is reported).

Bob

[Dennis Roberts]

On Apr 8, 2010, at 3:03 PM, Scott Cantor wrote:

> It may be the case that using javascript directly to affect the cookie store
> has different behavior, but if that were the "solution", I'd have to
> generate something with Javascript in it, and right now all of the normal
> flows in the SP are redirects.

Good point. I'll look for a way to detect these cookies and delete them in our application if necessary.

Thanks,
Dennis

[Dennis Roberts]

On Apr 8, 2010, at 3:24 PM, Scott Cantor wrote:

> For clarification, there are orphaning scenarios such as accessing an SP and
> then never returning to it. That leaves a state cookie in place for the
> session. That's the only cookie that isn't just recycled. The authentication
> session cookies all have fixed per-SP/app names, not random ones, so one
> login just overwrites the previous one.

Thanks for the clarification; I believe that the cookies that were accumulating were state cookies.

Dennis

[Scott Cantor]

> For clarification, there are orphaning scenarios such as
> accessing an SP and then never returning to it. That leaves a state cookie in place
> for the session.

Sorry, another thought on that...your particular issue is undoubtedly with those cookies, so a solution that comes to mind is switching the relayState mode at the SP from "cookie" to the storage service option(ss:mem, I think? see docs and recent thread on that on the list).

That's a compelling enough advantage, given the way Firefox works, to make me consider changing the default like Lukas wanted.

-- Scott

[Dennis Roberts]

> (In our SP's case, they
> could not do this without introducing loops, as they do not force SSL-only
> access, so for now I think they just tell users to clear their cookies
> when such a problem is reported).

Thanks for the info. Unfortunately, we're in the same boat.

Dennis

[Dennis Roberts]

> Sorry, another thought on that...your particular issue is undoubtedly with those cookies, so a solution that comes to mind is switching the relayState mode at the SP from "cookie" to the storage service option(ss:mem, I think? see docs and recent thread on that on the list).

Thanks; I'll give that a try.

Dennis