incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Zlatanov <...@lifelogs.com>
Subject Re: Cassandra access control
Date Wed, 02 Dec 2009 21:55:16 GMT
On Wed, 2 Dec 2009 15:32:35 -0600 Jonathan Ellis <jbellis@gmail.com> wrote: 

JE> 2009/12/2 Ted Zlatanov <tzz@lifelogs.com>:
>> I'd still rather pass something back.  As I said, it allows backends to
>> maintain state when it makes sense to do so and can alleviate the
>> problem of redundant auth queries in the future.

JE> That makes no sense whatsoever.  Backends can maintain state or not
JE> either way; adding a token you have to pass back makes just adds an
JE> extra layer of mapping token -> real state in the simple case of
JE> token-is-only-valid-per-connection and an unreasonable amount of
JE> complexity if you try to make it valid across more than one.

JE> I'm -1 in the apache veto sense on the token idea.

On Wed, 02 Dec 2009 15:38:14 -0600 Eric Evans <eevans@rackspace.com> wrote: 

EE> If not for SSO via shared-state between nodes, then for what? Can you
EE> give a tangible example of "when it makes sense to do so"? Are you sure
EE> this isn't YAGNI? 

Across nodes, backends can't maintain state easily, and even across
threads it's not trivial.  My version allows a distrubuted application
to authenticate once and then reuse the same AuthenticationRequest, as
long as the authentication backends have a permanent token store inside
or outside Cassandra.  If we're going to make the keyspace choice sticky
per connection, we should allow for a way to open multiple connections
to multiple keyspaces without necessarily hitting auth services every
time.

You claim the complexity is unreasonable.  I disagree.  If any
complexity emerges, it will be in the backend code which a particular
organization may need and will write.  For Cassandra itself this is not
an issue and the default case (AllowAll) will not create any such
complexity.

Ted


Mime
View raw message