cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Zlatanov <>
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 <> wrote: 

JE> 2009/12/2 Ted Zlatanov <>:
>> 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 <> 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

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


View raw message