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
 gcdcu-cassandra-user@m.gmane.org designates 80.91.229.12 as permitted sender)
To: cassandra-user@incubator.apache.org
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Cassandra access control
Date: Thu, 12 Nov 2009 10:20:14 -0600
Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @
 Cienfuegos
Lines: 53
Message-ID: <87639fr9z5.fsf@lifelogs.com>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux)
Cancel-Lock: sha1:4ryENM0oIPxZpMeWDURY2tY1WOQ=
Sender: news <news@ger.gmane.org>

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