cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <eev...@rackspace.com>
Subject Re: Cassandra access control
Date Tue, 01 Dec 2009 20:23:47 GMT

Sorry for chiming in so late, travel and the thanksgiving holiday got
the better of me.

On Mon, 2009-11-30 at 16:34 -0600, Ted Zlatanov wrote:
> I posted the first attempt (with a default AllowAll backend) as a
> patch:
> 
> https://issues.apache.org/jira/browse/CASSANDRA-547
> 
> Important changes in the Thrift interface:
> 
> # invalid authentication request (user does not exist or credentials
> invalid)
> exception AuthenticationException {
>     1: required string why
> }
> 
> # invalid authorization request (user does not have access to
> keyspace)
> exception AuthorizationException {
>     1: required string why
> }
> 
> ...
> 
> struct AuthenticationRequest {
>     1: required map<string, string> credentials,
> }
> 
> service Cassandra {
>   # auth methods
>   # authentication
>   void login(1:required AuthenticationRequest auth_request) throws
> (1:AuthenticationException aux),
>   
>   # authorization
>   void setKeyspace(1:required string keyspace) throws
> (1:AuthorizationException azx),
>   string getKeyspace(), 

I'm personally not a big fan of the setKeyspace()/getKeyspace() idea.
Getting rid of the keyspace argument makes sense because the keyspace is
the highest (or lowest), level of the data-model so its implicit that an
application need only talk to one. If removing that argument makes sense
(and I think it does), then we should just do that. Accessing more than
one keyspace is a corner case IMO, but its one that can be accommodated
by opening another connection.

Also, I don't know how others feel, but I'm not comfortable committing
anything that would be a candidate for 0.5 that isn't more fully baked
at this point. So I'd rather see something that is at least minimally
useful targeted for 0.5+1 


-- 
Eric Evans
eevans@rackspace.com


Mime
View raw message