incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Mischo <jmis...@quagility.com>
Subject Re: bandwidth limiting Cassandra's replication and access control
Date Thu, 12 Nov 2009 02:44:14 GMT
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


Mime
View raw message