[pubcookie-dev] Single Sign Out
schwoerb at doit.wisc.edu
Thu Jun 22 06:02:07 PDT 2006
On 6/21/06 11:05 PM, "Jim Fox" <fox at washington.edu> wrote:
>> We are working on a couple of enhancements for pubcookie, the biggest being
>> a Single Sign Out mechanism and we are seeking feedback.
> I knew my long procrastination on this issue would pay off.
>> We have in dev a successful mechanism where we write a cookie scoped at the
>> login server for each appsrv + appid they visit (ie
>> pubcookie_l_track_appsrv_appid). The contents of the cookie at this point
>> is the appid, relay_url, and redirect_url, with only the first two being
> These cookies also allow the login server, in pinit mode, to say
> "You are still logged into ...."
> The cookies ought to include a timeout time. When a timeout expires
> the login server can delete the cookie. Each app ought to have a
> display name as well. That way, if a message to the user is needed,
> it can make sense.
> Both of these could be communicated in a granting request. Or they
> might be preloaded into the login server for selected apps.
> I think these 'login' cookies can be plain text.
Jon Miner has it coded to be base64 encoded at this point. He does have a
time in the cookie I can not tell what it is for, and he is on vacation to
Jamaica. The timeout value for the cookie different than the login cookie
timeout is questionable for usefulness, or at least the way I see it. The
app will continuously have a new timeout with usage unless it sets a
>> The thought is to have on full logout, it to add hidden iframes on the
>> logout page that will have the location be the
> The problem here is that the browser user has no way of knowing
> if or when each logout has succeeded. If the message is, "Thank
> you for logging out," the user may stop or go to a new page
> before all the logout iframes have completed. If the message is
> "Logging you out," then how long does the user wait?
> If you instead put each app's logout redirect in a visible iframe
> you can show something like:
> Logging out of <app 1 display name>, status: [iframe logout url]
> Logging out of <app 2 display name>, status: [iframe logout url]
> Each logout url could display "Logged out" on successful logout.
> The user gets a positive response.
I do like this idea of listing apps in combination with Jon Warbrick's idea
for an image. The one thing that might be confusing are small applets, like
we use in our portal. They are iframes to other servers that the user will
have no idea that they logged into.
> An alternate approach might be:
> On logout of an app (LOGOUT_REDIRECT) the login server:
> 1) deletes that app's 'login' cookie.
> 2) Takes the next 'login' cookie:
> Show "Logging out of <display name>",
> with a reload of the app's logout url.
> 3) The app's logout url deletes its session cookies
> and redirects to the login server using the normal
> app PBC-LOGOUT mechanism.
> 4) Repeat for next app.
> server is aware of each app's status. It would hang on a failed
> logout - but maybe that's what we want.
>> We understand that it may end up with many tracking app cookies, but it
>> should work. It is also stateless without needing to replication login
>> session information across all of the login servers.
> I wouldn't worry about too many cookies if we delete expired ones.
> The stateless part is most beneficial.
> One more consideration:
> A common practice for applications is to use pubcookie to get
> started, but to create and maintain their own application session
> cookies. Several of our more popular apps do this. These apps
> will need to be logged out as well.
> One possibility is to add some module directives:
> <app timeout> use as described above
> <app name> ditto
> <app logout url> app_logout_url
> <app session time> seconds
> When the module gets a logout request it first deletes its own
> session cookies and then redirects to the app's logout_url.
> The app may be required to redirect back to the login server's
> LOGOUT function -- depending on the specific logout method.
That is very true about apps handling their own sessions, it wasn't
something we had thought of, but that is why we emailed here. This needs
more thought to be done well.
More information about the pubcookie-dev