Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jmischo@quagility.com
 designates 216.154.210.211 as permitted sender)
Message-Id: <0929D1DE-EAB9-4ACD-BBA0-F22A3AD5F98A@quagility.com>
From: Jonathan Mischo <jmischo@quagility.com>
To: cassandra-user@incubator.apache.org
In-Reply-To: 
 <764B352CF55C514F816B4B14BD2450D8019A1D51@bcs-mail04.internal.cacheflow.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: bandwidth limiting Cassandra's replication and access control
Date: Wed, 11 Nov 2009 20:44:14 -0600
References: <87eio6p7pb.fsf@lifelogs.com>
 <e06563880911101153j60552e58h417fe8f896ca6ce@mail.gmail.com>
 <87ljienhjx.fsf@lifelogs.com>
 <e06563880911101509t7b457941q49394a000f6e639c@mail.gmail.com>
 <87hbt1nnur.fsf@lifelogs.com>
 <764B352CF55C514F816B4B14BD2450D803DBB97B@bcs-mail04.internal.cacheflow.com>
 <cdc5ad200911111344v38c44732h57a0305fa62d57cc@mail.gmail.com>
 <764B352CF55C514F816B4B14BD2450D803DBBF2C@bcs-mail04.internal.cacheflow.com>
 <BEDD8E0E-A3F7-41D1-8103-22C761D3E147@quagility.com>
 <97635523-9F34-4A3B-81AB-A2DDFA1E4BDC@Holsman.net>
 <764B352CF55C514F816B4B14BD2450D8019A1D51@bcs-mail04.internal.cacheflow.com>

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