completing cosign logout

[Gavin Eadie <gavin@xxxxxxxxx>]

I asked my original question of one of the cosign team and, along 
with his reply, he suggested it would be good if cosign-discuss saw 
the exchange, and it entered the record, so I reproduce it here 
(edited for the retelling) for wider appreciation.
_______________________________

[We] noticed that one of the WebObjects applications appears to not 
be logging out properly.  The effect is that after telling weblogin 
to logout the user can re-enter the application without logging in 
again.

I watched the cookie creation and destruction through login, usage, 
and logout and it looks to me that, for the applications in question, 
the cosign "service" cookie persists through logout.  When I watch 
the same things for mail.umich, for example, the equivalent cookie is 
gone after logout.

I obviously very much doubt cosign has a weakness that allows this, 
and so suspect that the application is persisting something across 
sessions [...] so, just a quick check to be sure I'm doing the right 
thing.  When the user clicks logout, the application sets up a 
redirect to:

    https://weblogin.umich.edu/cgi-bin/logout

        and sets a flag which terminates the session after the end of 
the request-response loop, and then lets the loop conclude with the 
transmission of the redirect to the browser.
_______________________________

Reply: ... the service cookie persists if you don't install a 
service-side logout.  There is an example perl script in the source 
distribution that deletes the service cookie before redirecting to 
weblogin's central logout.

Before redirecting to https://weblogin.umich.edu/cgi-bin/logout it 
should set the service cookie to the word "null" and set it to an 
expiration time that has already passed.

The problem is two-fold:  (1) the weblogin server can't see your 
service's cookie (and thus can't expire it) and (2) to reduce load on 
the cosign server there is a short-lived service-side cache of 
authentication information that the filter will consult prior to 
checking the cookie with the central service (for, by default, 2 
minutes).
_______________________________

Subsequent (my bad) to this conversation, I found references to this 
behavior, and its remedy, in the FAQ and documentation, but there's 
less detail there than was explained to me in this message.


FAQ:  After I logout I can still access my Cosign Protected service 
for a small window of time. Is Cosign broken? What's wrong?

Cosign is not broken and you have done nothing wrong. You merely need 
to customize and make use of the local logout script provided in 
scripts/logout. The filters have a cache time (default 2 minutes) 
during which they will not validate a user's status. As such, when a 
user returns post logout, the cache is still valid and the user is 
still "logged in" to that one site for a few seconds. To avoid this, 
simply call the local logout script which will re-direct the user to 
the main logout script.


and http://weblogin.org/README.scripts.txt:

logout:
    The scripts directory contains scripts that might be useful when
    running a cosign weblogin server or authentication filter.

    The scripts in 'logout' do not replace the central logout cgi (
    that runs on the weblogin server ) but are intended to run on
    authentication filter hosts ( clients of the central weblogin
    server ).  These scripts expire and nullify the service's cosign
    cookie, provide an opportunity for local session cleanup, and
    redirect the user to the central logout cgi ( where he or she may
    choose to terminate the cosign session ).  This eliminates the
    problem of logged out users backing up to an authenticated site
    before the site's local cookie cache has expired.

    These logout scripts are not intended to present any html to the
    user.  You should, however, make allowances for appropriate error
    screens if your session cleanup is somehow destructive ( e.g. there
    are unsaved changes pending ).