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: <93FD370D-A3BC-4EF4-AE52-6C9CB9C3B778@quagility.com>
From: Jonathan Mischo <jmischo@quagility.com>
To: cassandra-user@incubator.apache.org
In-Reply-To: <87639fr9z5.fsf@lifelogs.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:36:41 -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>
 <87639fr9z5.fsf@lifelogs.com>

Conditional +1 here:

+1
IF the Keyspace parameter is optional in 0.6 forward, but not  
completely eliminated
AND IF login() has an optional param for keyspace
AND IF the backend stores a list of keyspaces you're authorized to  
access once you're authenticated if you don't specify a single  
keyspace you're authenticating to (this should be very simple and  
lightweight)

Does that all make sense?  The second note above is probably not  
strictly necessary for 0.5, but it streamlines the third note, since  
in 90+% of cases, you'll be working with a single keyspace and can  
save overhead by just authenticating to that single keyspace.

On Nov 12, 2009, at 10:20 AM, Ted Zlatanov wrote:

> On Thu, 12 Nov 2009 10:06:02 -0600 Jonathan Ellis  
> <jbellis@gmail.com> wrote:
>
> JE> 2009/11/12 Ted Zlatanov <tzz@lifelogs.com>:
> JE> The default should definitely be, "don't break people who don't  
> need
> JE> the new feature more than necessary."  So the default should be
> JE> "accept any client to any keyspace."
>>>
>>> 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?
>
> JE> If this is going to 0.5 we should keep the existing API intact  
> since
> JE> we are very late in the 0.5 cycle (so, it's up to you if you  
> need this
> JE> in 0.5).  But ultimately we want to drop the keyspace args in  
> which
> JE> case the no-auth-configured behavior is that you still send an  
> auth
> JE> method call but the auth accepts whatever it is given.
>
> I see.
>
> So I'm adding a login() in 0.5 but keeping the Keyspace parameters
> everywhere.  If the user has authenticated via login(), the Keyspace
> logged in will be checked against the specified Keyspace (and  
> exceptions
> thrown if they don't match).  Otherwise, no check is done.  This keeps
> the current API and behavior intact but adds the desired  
> functionality.
> The exception will point the user to the problem immediately.
>
> For versions after 0.5, the current API calls with the Keyspace
> parameter will be removed in favor of versions without it.  login()  
> will
> be required to specify the Keyspace regardless of whether  
> authentication
> is done or not.  The only expected security exception here comes from
> login().  Once you're authorized, the grant doesn't expire.
>
> If you're OK with all this I'll put together a full proposal in the  
> Jira
> ticket and start working on a patch to:
>
> - add the login() method
>
> - add an authentication+authorization interface called in the right
>  places in 0.5
>
> - implement that interface: provide a XML backend and a LDAP backend  
> (no
>  JAAS).  Also, a AllowAll backend will be provided.
>
> - add the configuration file stanza to point to the
>  authentication+authorization module to be used.  Make AllowAll the
>  default auth backend there.
>
> - document all the changes
>
> Thanks
> Ted
>