Brett @Google wrote:
On Thu, Oct 22, 2009 at 5:44 PM, Howard Chu <hyc@symas.com mailto:hyc@symas.com> wrote:
In the case of a local, load-balanced cluster of replicas, where the network latency between DSAs is very low, the natural coalescing of updates may not occur as often. Still, it would be better if the updates didn't happen at all. And in such an environment, where the DSAs are so close together that latency is low, distributing reads is still cheaper than distributing writes. So, the correct way to implement this global state is to keep it distributed separately during writes, and collect it during reads.I'd think that to indicate the topology you would create some administrative name, perhaps a simple string "sales west" or "cluster one" to indicate a topological region, and you would specify for each DSA which administrative name or topology it is logically part of. Then this administrative region name + unique identifier of the principal in question, could be used as a key to hold a simple locked / unlocked boolean value on the replica's parent.
I'm not sure you're trying to solve the right problem yet. I'm pretty unconvinced that account lockout is a good solution to anything, in general. That's why I added login rate control to the latest ppolicy draft, where the DSA simply starts inserting delays before responding to failed authc attempts. As I see it, rate control can be managed completely within a single DSA and no state ever needs to be replicated outward on any particular schedule. But at the moment I haven't yet thought about how well this will work in all the possible deployment scenarios.
So once again, what's important here is to analyze what are the types of attacks we expect to see, and how particular defense strategies will behave, and how effectively they will fend off those attacks. Until you've outlined the problems, you don't have any framework for designing the solution.