Peter Mogensen <[email protected]> writes: > Yes, yet another logout question. Sorry about that :)
> From what I understand, the recommended logout procedure is to include a > page in the web application destroying the app-token session and proving > a link to the https://weblogin/logout page to destroy the SSO cookie and > telling the user to close the browser application. Well, I would put it this way: the recommended logout procedure is for the user to close their browser. All the rest is an incomplete hack that you can also do and that might help, but the only guaranteed logout mechanism is to flush the session cookies. > I know that it's a feature that WebAUTH doesn't set any domain cookies, > but targets each cookie to the specific host, but what would > theoretically be wrong with including a domain cookie common to all > applications (in those setups where that's possible) to let an > application verify that there's still a live SSO session, requiring > there to be one before accepting the application session and potentially > destroy that cookie, terminating all application sessions, when the user > logs out? Unless that cookie is authenticated, it means that logout doesn't actually log you out in the presence of an attacker, since the attacker will just set that cookie and then can use all the existing session cookies, yes? And I'm not clear on how to authenticate that cookie within the WebAuth protocol. You would really need public key cryptography to authenticate a global cookie, with the WebKDC publishing a public signing key. Admittedly, that attack would require a knowledgable attacker with the ability to manipulate the cookie cache, so it's unlikely to be successful in a typical kiosk environment. However, any solution involving domain cookies only works if all your WebAuth-protected servers are within one domain, something that WebAuth does not assume and which is not true of, for example, Stanford. > I see that there's reasons in some WebAUTH setups why domain cookies are > a bad idea - namely those where SSO is handles without cookie by HTTP > Negotiate. Domain bearer cookies that carry authentication data are *always* a bad idea, regardless of how they're generated, since they can be trivially stolen and then used to pretend to be the user. Domain cookies are ridiculously insecure. Now, that's not quite what you're talking about -- you're talking about a cookie that represents an assertion about the login state without carrying authentication data, so stealing that cookie isn't particularly interesting. But the problems of cross-domain authentication mentioned above still apply. The secure way to do site-wide logout is for each WAS to ask the WebKDC whether a particular user authentication is still valid on some regular basis, and for the WebKDC to store login state. This is the approach that Cosign took, since site-wide logout was a design goal for them. WebAuth had a competing design goal (minimal central state for easy scaling of WebLogin servers) that conflicted with storing central login status. It's kind of hard to get both at the same time. (I've played around with the idea of implementing the Cosign protocol in parallel to the WebAuth protocol, but I've never had the time.) One approach that one other WebAuth site was considering was to support site-wide logout only for browsers with Javascript support (and with Javascript enabled). The idea would be that the WebLogin server would store, in browser local storage, the list of sites to which the user authenticated, and then when you hit the WebLogin logout page, it would use Javascript to tickle a known logout URL for each one of those sites inside the browser so that each site could clear its own cookies. That would work, although it's a bit of implementation effort and requires exposing a logout URL on all your WebAuth-protected sites (which is very difficult to do for WebAuth-protected proxy servers). > The FAQ mentiones something about NAT traversal. But how does that > influence such a solution? I should really clean out some of that old discussion in the FAQ, as there probably isn't even anyone at Stanford who would remember the old system enough to ask those questions. The discussion of NAT is specific to the previous single sign-on system that Stanford used, which involved a protocol called S/Ident that was vulnerable to serious man-in-the-middle attacks. It's not really relevant to what you're talking about. -- Russ Allbery <[email protected]> Technical Lead, ITS Infrastructure Delivery Group, Stanford University
