Search Mailing List Archives
bcodding at uvm.edu
Wed Dec 12 13:57:15 PST 2012
On Dec 12, 2012, at 12:45 PM, Russ Allbery wrote:
> I agree that in your case with a maximum of five services, it's probably
> not a problem, but I'm worried that it could be in the more general case,
> particularly for people using Active Directory as their KDC. That said,
> that shouldn't prevent you from proceeding with that approach. I'd just
> kind of like to support web storage as well in the official release.
We have WAS tracking in a cookie for logout and are aware that max header
sizes could be a problem for us -- we're growing services pretty quickly --
but it hasn't come up as a problem yet (that we know of).
One of the most attractive things about WebAuth is its stateless server..
this is a beautiful thing.
> A third possible alternative is that WebAuth 4.4.0 (which is almost
> finished) will add support on the WebLogin server for using memcached to
> store some state data. Initially, this will only be used for optional
> replay caching and optional temporary account lockout after too many
> failed login attempts, but it could very easily be used for sitewide
> logout data as well.
> The one caveat to that is that memcached doesn't (so far as I can tell)
> have a pool replication protocol, so one is dependendant on a single
> memcached server that could, of course, go away. But having sitewide
> logout fail in that situation and tell the user to close their browser
> would probably be fine.
There are ways to make memcached redundant and reliable. Though, if I had
to choose between maintaining a fault-tolerant stateful platform or
abandoning those with script disabled, I'd leave the scriptless behind. Is
that terrible? Maybe, but WebAuth is a rock right now.
One last thing -- Klaus, you might think about not sending the user's
browser on a wild ride around a ring of WASes -- rather have the WebLogin
server generate a page with a resource to load from each WAS. That way,
users won't get lost on the ride if a WAS behaves badly, and you don't have
to worry about sending the WAS chain info along the way.
More information about the webauth-info