That's the essential idea, although I think Ted's hoping to make it configurable to talk to other auth providers as well.
On Wed, Nov 11, 2009 at 8:38 PM, Coe, Robin <robin....@bluecoat.com> wrote: > Ok, this makes sense. I was looking at this as a real security service > but I think I understand where you're going with this. Again, forgive > me for being a Cassandra newb. > > If the idea is to add a per-keyspace token in the storage.conf and open > the thrift connection using that token, then I agree, this would be a > pretty simple solution and not a performace hit. > > Have I finally understood the proposal? > > Robin. > > > -----Original Message----- > From: Jonathan Ellis [mailto:jbel...@gmail.com] > Sent: Wed 11/11/2009 18:26 > To: cassandra-user@incubator.apache.org > Subject: Re: bandwidth limiting Cassandra's replication and access control > > On Wed, Nov 11, 2009 at 8:17 PM, Coe, Robin <robin....@bluecoat.com> wrote: >> I completely agree with Ian but would also like to add a point about the >> proposed service. As was presented, the authentication is to be performed >> at the Thrift API layer, not the CLI layer. In a relational database >> environment, this would be equivalent to connections opened over a >> network. In this environment, all connections share the same user account, >> which is not per-user authentication. > > As Ian points out, most applications get by fine with a single user. > So keyspace auth provides app level auth, not really user-level. > Which is a great 80% solution. (Really more like 95% I would say.) > >> I would still like to understand why there is the need to impose a keyspace >> binding, from a security standpoint. > > You don't want any app to be able to accidentally or maliciously touch > another's data. Jonathan Mischo gave a bunch of excellent reasons why > this is so. > >> Beyond that, how will tokens be shared amongst all >> the nodes in a cluster > > they don't need to be. > >> such that a user returning to a different node >> maintains the keyspace binding and do so without affecting performance? > > We're only trying to provide authentication, not some cross-connection > session. Each connection will authenticate individually. > > -Jonathan > /gave up on trying to move this to -dev > >
