CoSign: Collaborative Single Sign-On  

cosign-discuss at
general discussion of cosign development and deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

completing cosign logout

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:

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 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.


    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 ).

Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010