Peter Mogensen <[email protected]> writes: > On 2012-09-04 18:45, Russ Allbery wrote:
>> 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? > Sure. The cookie needs to be authenticated. >> 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. > Yes... that was my thought too. But to be honerst, I didn't think too > much about it except convincing myself that at least this could be done > with public key cryptography. Same here. :) I'm sure that it can be done with a public key signature, but I think that's the tool that would be needed, which would mean adding some sort of direct public-key component to the WebAuth protocol. (Right now, it doesn't use any public-key cryptography apart from TLS to protect various web connections.) > Exactly. I was trying to find a way for global logout under the premise > that every application server shared the same higher level domain. >> 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. > Yes.. thought about that too. Made the JavaScript guys scream :) Heh. :) I guess what I would say on this front is that, first, were I to try to free up some development resources to put some concentrated effort into site-wide logout, I would probably instead implement state replication between the WebKDC servers (maybe leveraging memcache or something) and a protocol for the WAS to query the WebKDC for login state periodically. This is akin to the Cosign protocol, so I'd want to take a long look at Cosign and see to what extent we could borrow or just implement it. However, second, the chances are quite low that I'm going to get to that any time soon. My current development roadmap is: - Proxying support in non-prod environments - Management of WebAuth keyrings via wallet - Replay cache for WebLogin logins - Rate limiting for failed WebAuth logins - Complete the native Java WebAuth implementation - WebAuth as a native Shibboleth IdP authentication method - Public open source release of the user information service - WebLogin support for user certificate authentication - mod_webauthldap support for LDAP groups - Rework the protocol as an OpenID Connect profile and logout would probably come either near the bottom of that list or after those things. And of course Stanford wants me to work on a bunch of other things as well, so WebAuth development can come in fits and starts. So, given that, I'm not going to have a chance to do the "right thing" any time soon, and I would welcome patches that implement simpler, if limited, measures, as long as they seem maintainable. So if anyone finishes the Javascript approach or a domain logout cookie approach, and the code looks simple and maintainable, I will certainly seriously consider merging it into WebAuth until such time as I can come up with something that I like better (if that ever happens). -- Russ Allbery <[email protected]> Technical Lead, ITS Infrastructure Delivery Group, Stanford University
