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 tve@rightscale.com designates
 72.14.220.152 as permitted sender)
Message-ID: <4AFC3C74.3080704@rightscale.com>
Date: Thu, 12 Nov 2009 08:48:52 -0800
From: Thorsten von Eicken <tve@rightscale.com>
Organization: RightScale, Inc.
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: cassandra-user@incubator.apache.org
Subject: Re: Cassandra access control
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>
 <93FD370D-A3BC-4EF4-AE52-6C9CB9C3B778@quagility.com>
In-Reply-To: <93FD370D-A3BC-4EF4-AE52-6C9CB9C3B778@quagility.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

+1
It's not a lot of complexity and it doesn't throw sticks into frameworks 
that may model a conventional table as a keyspace.
    Thorsten

Jonathan Mischo wrote:
> 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
>>
>