Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Consider Cookies w/Fixed Expiration as Mitigation for Browser Session Restore

Description

Many browsers restore sessions across browser restarts by default, which prevents clearing SSO session state cookies by closing the browser. The following was suggested on cas-user as a solution:

It was suggested on the shib-users mailing list that we should change cookie expiration policies from "expires at end of session" to "expires at time XYZ". At least browsers will honor a time-based expiration, for now!

Environment

None

Activity

Show:

Jérôme LELEUOctober 7, 2013 at 1:11 PM

Noticed.

Marvin AddisonOctober 3, 2013 at 3:41 PM
Edited

I would like to add one observation before closing the issue. For browsers that have a durable notion of session, the CASTGC cookie can be transmitted well after the CAS SSO session has expired. In CAS 3.5.x that causes the generic login page to be displayed when in fact the session has long ended. With CAS 4.x that behavior will be prevented by the new ticketGrantingTicketCheck webflow action. Setting an explicit expiration date on the cookie could help reduce the likelihood of that surprising behavior in 3.5.x.

Jérôme LELEUSeptember 11, 2013 at 7:34 AM

By "here", you mean on this JIRA ?

My little contribution : I agree with Scott but I would argue another way.

The problem is not linked to the CAS server : the problem would happen for all applications having a session cookie which lasts the web session. So even if we secure the CAS server with a double cookies mechanism (this adds complexity), all applications protected by the CAS server would have the same problem and their sessions would be restored even if the CAS one is not.
I have more than 200 applications integrated with my enterprise CAS server and you would access to ALL of them just by restoring the JSESSIONID or the PHPSESSIONID cookie.

So far, the CASTGC cookie exists during the web browsing and only the CAS server knows if the session is expired (idle & hard timeout). I'm not very enthousiastic about providing security information through the expiration date of the cookie, but above all, this double mechanism does not work because of the proxy mechanism. When proxying, we don't have access to the client cookies and the CAS server is thus unable to update the CASTGC expiration date.

Hope it helps. Marvin, feel free to close the JIRA at your convenience...

Marvin AddisonSeptember 10, 2013 at 1:39 PM

I agree with Scott's analysis. I think it's worth considering alternatives and documenting them here even if it's a futile effort. Interest in mitigating browser session restore is sufficient that it would be worthwhile to document our efforts even if ultimately unsuccessful; then we could simply point users to this issue for background. Who knows, someone propose a novel approach in the future.

Jérôme LELEUSeptember 10, 2013 at 11:58 AM

Should we resolve this one as "Won't fix" ?

Won't Fix

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

Created July 9, 2013 at 5:11 PM
Updated October 7, 2013 at 1:12 PM
Resolved October 7, 2013 at 1:12 PM