Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-user@incubator.apache.org
Received-SPF: pass (athena.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: Wed, 02 Dec 2009 14:19:13 -0600
Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @
 Cienfuegos
Lines: 47
Message-ID: <877ht5jfi6.fsf@lifelogs.com>
References: <87eio6p7pb.fsf@lifelogs.com>
	<DC6830C8-E88C-4D2F-B4E2-A63088599D01@quagility.com>
	<e06563880911120849p4deea68dj4cc95bc9531c62d0@mail.gmail.com>
	<87fx8jptkn.fsf@lifelogs.com> <874oozpqcw.fsf@lifelogs.com>
	<87einfr6a8.fsf@lifelogs.com> <1259699027.19220.37.camel@achilles>
	<87fx7ul6id.fsf@lifelogs.com> <1259708330.19220.59.camel@achilles>
	<87638pl96u.fsf@lifelogs.com>
	<ff1a07b80912020713n2485e001x6a9df005d905b62f@mail.gmail.com>
	<4B16BC76.7030105@dehora.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux)
Cancel-Lock: sha1:6yn2Zgcn45ft46dCilmKOWV2a0M=
Sender: news <news@ger.gmane.org>

On Wed, 02 Dec 2009 19:13:58 +0000 Bill de hOra <bill@dehora.net> wrote: 

Bdh> Strong agreement. The login method should return an opaque token which
Bdh> is passed on each call. If that messes up the API, that says more
Bdh> about Thrift than the auth model.

Slight disagreement on the semantics: this is not a stateless protocol
anymore.  Both the client and the server now need to keep track of these
tokens and set expiration policies on them, throw token validity
exceptions, etc.  It's useful for sure, but not stateless.  I'll put you
down for stateless but you may want to comment further.

So the question then flows into Robin's note:

On Wed, 2 Dec 2009 11:59:57 -0800 "Coe, Robin" <robin.coe@bluecoat.com> wrote: 

CR> Once a connection is opened with credentials, then as long as I hold
CR> that connection open, I shouldn't need to pass auth checks with
CR> every transaction.

Right, so you're on the stateful side.  With Bill's vote we're 3-2 in
favor of stateful.

CR> On the other hand, if there was a way to use a token in lieu of
CR> credentials, to provide SSO capabilities to any node, then I could
CR> see their use.  Checking whether a token exists in a local
CR> collection would be much faster than having to pass through an
CR> authentication/authorization framework.  However, as there's no way
CR> to ensure immediate consistency of tokens across all nodes, it's
CR> probably not worth the effort of making Cassandra "token aware",
CR> since an application would have to provide fall-back logic to
CR> authenticate with credentials, if the token fails.  So, tokens would
CR> probably just add complexity without much benefit.

The credentials are a map so it's trivial to add any credential (e.g. a
GPG signed keyspace authorization request, Kerberos tokens, or
Cassandra's own tokens).  I think each AuthenticationBackend
implementation should implement its own scheme (being careful not to
overlap map keys), so certainly SSO is a possibility.  Of course you
should be able to have an AuthenticationOrBackend that combines two or
more other backends, so it would for example try tokens first and then
fall back to the slower credentials.  The application wouldn't have to
provide any fall-back logic.  To accomplish this, though, the
credentials will have to be returned by the login() method at the Thrift
level.  I'll make the change.

Ted