incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Coe, Robin" <robin....@bluecoat.com>
Subject RE: bandwidth limiting Cassandra's replication and access control
Date Thu, 12 Nov 2009 03:21:42 GMT
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:jmischo@quagility.com]
Sent: Wed 11/11/2009 18:44
To: cassandra-user@incubator.apache.org
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



Mime
View raw message