cosign-discuss at umich.edu
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
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
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
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 ).