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 jbellis@gmail.com designates
 209.85.218.210 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=Pz6NycCLB1cU1SiHD7H8/3fs3/xnJcZBovl9lTR0R9ObWrSPa9HI0l0vroYV171iFA
         IZKT24sgaq02A/I/6Vhp7WnxXv7OdHrdviZolvJx0k9lNBviAigcCy5GyO+xcsWec8Sm
         l1ghf6YYjgaTs0hZ14hmrFmmKGuAKjpVGAgDQ=
MIME-Version: 1.0
In-Reply-To: <87639fr9z5.fsf@lifelogs.com>
References: <87eio6p7pb.fsf@lifelogs.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>
From: Jonathan Ellis <jbellis@gmail.com>
Date: Thu, 12 Nov 2009 10:22:08 -0600
Message-ID: <e06563880911120822w58f37d69m64963772a6efd38c@mail.gmail.com>
Subject: Re: Cassandra access control
To: cassandra-user@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1

2009/11/12 Ted Zlatanov <tzz@lifelogs.com>:
> On Thu, 12 Nov 2009 10:06:02 -0600 Jonathan Ellis <jbellis@gmail.com> wro=
te:
>
> 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." =A0So 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. =A0You want to keep allowing multiple keyspaces? =A0That would l=
eave
>>> the existing API intact (only adding a login function) but requires an
>>> extra authorization check every time a keyspace is given. =A0Do we expi=
re
>>> 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 thi=
s
> JE> in 0.5). =A0But 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. =A0If 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). =A0Otherwise, no check is done. =A0This keep=
s
> 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. =A0login() wil=
l
> be required to specify the Keyspace regardless of whether authentication
> is done or not. =A0The only expected security exception here comes from
> login(). =A0Once 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
> =A0places in 0.5
>
> - implement that interface: provide a XML backend and a LDAP backend (no
> =A0JAAS). =A0Also, a AllowAll backend will be provided.
>
> - add the configuration file stanza to point to the
> =A0authentication+authorization module to be used. =A0Make AllowAll the
> =A0default auth backend there.
>
> - document all the changes
>
> Thanks
> Ted
>
>