Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jmischo@quagility.com
 designates 216.154.210.211 as permitted sender)
Message-Id: <5B7ECCB8-BF96-4EA1-AAB7-B8C27B824FDF@quagility.com>
From: Jonathan Mischo <jmischo@quagility.com>
To: cassandra-user@incubator.apache.org
In-Reply-To: <e06563880911120806w70becf6eu50efef0efcd72a88@mail.gmail.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: Cassandra access control
Date: Thu, 12 Nov 2009 10:23:21 -0600
References: <87eio6p7pb.fsf@lifelogs.com> <87hbt1nnur.fsf@lifelogs.com>
  <764B352CF55C514F816B4B14BD2450D803DBB97B@bcs-mail04.internal.cacheflow.com>
  <9c50e66d0911111429n1f23c01ct7a0d3afef3d0a6f6@mail.gmail.com>
  <13FB79D2-F083-46D0-BD2A-02F915144322@joestump.net>
 <e06563880911111455gc9f5c10g1863bbacdcead348@mail.gmail.com>
  <20091112001409.GC12953@alumni.caltech.edu> <878webssu6.fsf_-_@lifelogs.com>
  <e06563880911120712m75051e0bv9dfec31cb634dd95@mail.gmail.com>
  <87iqdfrba9.fsf@lifelogs.com>
 <e06563880911120806w70becf6eu50efef0efcd72a88@mail.gmail.com>


On Nov 12, 2009, at 10:06 AM, Jonathan Ellis wrote:

> 2009/11/12 Ted Zlatanov <tzz@lifelogs.com>:
>> Hmm, I thought we were going to limit access to a single keyspace  
>> upon
>> login.  You want to keep allowing multiple keyspaces?  That would  
>> leave
>> the existing API intact (only adding a login function) but requires  
>> an
>> extra authorization check every time a keyspace is given.  Do we  
>> expire
>> authorizations after a certain time?
>
> If this is going to 0.5 we should keep the existing API intact since
> we are very late in the 0.5 cycle (so, it's up to you if you need this
> in 0.5).  But ultimately we want to drop the keyspace args in which
> case the no-auth-configured behavior is that you still send an auth
> method call but the auth accepts whatever it is given.
>
The problem I see with this is that you can't have a single connection  
accessing multiple keyspaces at once.  I can think of some cases where  
having a single connection access and differentiate between two  
keyspaces would be advantageous, especially in certain kinds of  
reporting applications.  Otherwise, you force the creation and  
maintenance of multiple connection pools on the client side, which  
isn't as resource efficient.

This goes back to the concept we were talking about on IRC yesterday  
where a single user may have access to more than one keyspace.  If you  
authenticate and the system authorizes access to multiple keyspaces,  
you should have access to them from the same connection, IMHO, since  
that's a pretty well established pattern.