Hi Jon, Yes, I understand now what was presented. I had definitely been thinking that the proposed solution was to tackle the actions on a per-user basis, requiring authentication with every transaction.
If the security layer in Cassandra is attached to the connection, with application security layered on top, then I'm a fan of implementing a connection-based authentication framework. And I agree that adding grants on actions, as per the RDBMS model, might be a nice-to-have in the long term. Robin. -----Original Message----- From: Jonathan Mischo [mailto:[email protected]] Sent: Wed 11/11/2009 18:44 To: [email protected] Subject: Re: bandwidth limiting Cassandra's replication and access control On Nov 11, 2009, at 8:17 PM, Coe, Robin 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 Any authentication that's performed should be performed for the particular connection. The CLI is still a connection, so it would still be authenticated. While it's true that there needs to be a mechanism in Thrift for authentication (which may or may not be present currently, as was briefly mentioned, I believe), the actual authentication and authorization would happen at the node level. > 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. I'm not sure what you mean by "In this environment" here. In the RDBMS world, it's connection-level authentication, and some combination of per-database, per-schema, per-action, per-table, per- row, or per-column authorization. A keyspace in Cassandra is the rough equivalent of what the RDBMS world calls a database or a schema, depending on the implementation. We're talking about connection-level authentication with per-keyspace authorization. We're also not currently talking about per-action authorization (i.e. insert or delete), though that could someday be a topic for discussion, if someone finds that they need a read-only role. Does this clarify things? -Jon
<<winmail.dat>>
