Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

Logout mechanism

Klaus Hueck klaus.hueck at physik.uni-hamburg.de
Wed Dec 12 09:32:39 PST 2012


Thank you for the quick reply!

On 12.12.2012 18:21, Russ Allbery wrote:
> Klaus Hueck <klaus.hueck at physik.uni-hamburg.de> writes:
>
>> concerning the missing logout feature in WebAuth we came up with a
>> logout mechanism which might work:
>
>>   - The Weblogin server creates yet another cookie (WebloginTrackCookie) in
>> which all services are listed which requested a token
>>   - If the user clicks the logout button in any of the services he is
>> logged in to, he will be forwarded to the logout site (WebAuthDoLogout on)
>> of the service. This logout site again forwards the user via a 303 http
>> forward to the logout url of the Weblogin server.
>>   - The weblogin server then looks up the WebloginTrackCookie to check if
>> there are still other services the user is logged in to.
>>   - If so, the user will be forwarded once more via a 303 forward to the
>> next logout site and so on and so forth.
>
>> Of course this scheme requires that all services have their own logout
>> site but - at least in our usage scenario - this is feasible and the
>> logout mechanism described above implemented here in our testing system
>> works like a charm.
>
>> If I remember right, there was already such a scheme proposed but it was
>> implemented by means of JavaScript instead of http forwards.
>
>> What do you guys think about such an logout mechanism?
>
> I think it sounds like a basically sound idea that would at least get us
> most of the way there.  The one thing that I'm worried about is the
> maximum cookie length.  WebAuth can already break due to exceeding the
> maximum cookie length on the WebLogin server with Active Directory
> Kerberos tickets with a large PAC.  Adding another long cookie could be a
> problem.

Since users in our usage scenario rarely use more than 5 services at a 
time the maximum cookie length considering the FQDN + /logout would be 
rather in the order of 200 characters. This shouldn't be a problem I 
think. The cookie really just contains the URL of the service without 
any other information.

> One of the motivating reasons for using JavaScript is that JavaScript lets
> you use web storage, which gets you out of having to create another long
> cookie at the cost of losing support for IE 7 and a few other older
> browsers.  I don't think you can examine web storage contents without
> using JavaScript.
>

Since many users in our department use JavaScript blocker JavaScript is 
no alternative.


More information about the webauth-info mailing list