I also like this feature, I also use keyspaces as another dimension
for some applications. I also don't worry about securing cassandra
as I run behind firewalls. I can see the argument for authentication
per keyspace, but I like it as optional.
For instance consider the use case where you have
On Tue, 01 Dec 2009 16:58:50 -0600 Eric Evans eev...@rackspace.com wrote:
EE On Tue, 2009-12-01 at 15:38 -0600, Ted Zlatanov wrote:
I disagree, why would you want to forbid switching the keyspace? That's
turning off a currently working feature. Also, connections are not
free, especially
2009/12/2 Ted Zlatanov t...@lifelogs.com
OK. So what should the API be? Just one method, as Robin suggested?
void login( MapString, String credentials, String keyspace )
throws AuthenticationException, AuthorizationException
In this model the backend would still have login() and
Sent: December 2, 2009 2:28 PM
To: cassandra-user@incubator.apache.org
Subject: Re: Cassandra access control
On Wed, 2 Dec 2009 15:13:11 + Mark Robson mar...@gmail.com wrote:
MR I'd be against moving to a stateful protocol.
Noted, I'd like to see some more votes. I'm agnostic: I think
On Wed, 2009-12-02 at 14:27 -0600, Ted Zlatanov wrote:
On Wed, 02 Dec 2009 14:14:53 -0600 Eric Evans eev...@rackspace.com wrote:
EE Did you maybe mean...? AuthenticationRequest required for the
EE method (has to be), but the map is optional?
Either way will work. With your suggestion
How about we make authentication optional, and have the protocol being
stateful only if you want to authenticate?
That way we don't break backwards compatibility or introduce extra
complexity for people who don't need it.
Mark
+1 this is nosql afterall.
Sent from my iPhone
On Dec 2, 2009, at 3:54 PM, Mark Robson mar...@gmail.com wrote:
How about we make authentication optional, and have the protocol
being stateful only if you want to authenticate?
That way we don't break backwards compatibility or introduce
On Wed, 2 Dec 2009 20:54:13 + Mark Robson mar...@gmail.com wrote:
MR How about we make authentication optional, and have the protocol being
MR stateful only if you want to authenticate?
MR That way we don't break backwards compatibility or introduce extra
MR complexity for people who don't
It's really premature to be holding a vote based on first-impression opinions.
2009/12/2 Ted Zlatanov t...@lifelogs.com:
On Wed, 2 Dec 2009 20:54:13 + Mark Robson mar...@gmail.com wrote:
MR How about we make authentication optional, and have the protocol being
MR stateful only if you want
it.
-Original Message-
From: Jake Luciani [mailto:jak...@gmail.com]
Sent: December 2, 2009 4:00 PM
To: cassandra-user@incubator.apache.org
Subject: Re: Cassandra access control
+1 this is nosql afterall.
Sent from my iPhone
On Dec 2, 2009, at 3:54 PM, Mark Robson mar...@gmail.com wrote:
How about we
On Wed, 02 Dec 2009 14:35:09 -0600 Eric Evans eev...@rackspace.com wrote:
EE On Wed, 2009-12-02 at 14:27 -0600, Ted Zlatanov wrote:
On Wed, 02 Dec 2009 14:14:53 -0600 Eric Evans eev...@rackspace.com wrote:
EE Did you maybe mean...? AuthenticationRequest required for the
EE method (has to
On Wed, 2 Dec 2009 15:23:23 -0600 Jonathan Ellis jbel...@gmail.com wrote:
JE It's really premature to be holding a vote based on
JE first-impression opinions.
Somehow we have to make a decision on whether the API will be stateful
or stateless. This affects more than just the auth code so I
On Wed, 2009-12-02 at 15:27 -0600, Ted Zlatanov wrote:
EE Let's not do that; as Robin pointed out...
EE ...there's no way to ensure immediate consistency of tokens
across all
EE nodes, it's probably not worth the effort of making Cassandra
token
EE aware, since an application would have to
I like this bug/feature it gives another dimension to play with.
Especially when keyspaces can be defined on the fly. Not a huge
restriction though.
Sent from my iPhone
On Dec 2, 2009, at 4:22 PM, Jonathan Ellis jbel...@gmail.com wrote:
What backwards compatibility are you concerned with
@incubator.apache.org
Subject: Re: Cassandra access control
+1 this is nosql afterall.
Sent from my iPhone
On Dec 2, 2009, at 3:54 PM, Mark Robson mar...@gmail.com wrote:
How about we make authentication optional, and have the protocol
being stateful only if you want to authenticate?
That way we
On Wed, 2 Dec 2009 15:32:35 -0600 Jonathan Ellis jbel...@gmail.com wrote:
JE 2009/12/2 Ted Zlatanov t...@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
Sorry for chiming in so late, travel and the thanksgiving holiday got
the better of me.
On Mon, 2009-11-30 at 16:34 -0600, Ted Zlatanov wrote:
I posted the first attempt (with a default AllowAll backend) as a
patch:
https://issues.apache.org/jira/browse/CASSANDRA-547
Important changes in
On Tue, 01 Dec 2009 14:23:47 -0600 Eric Evans eev...@rackspace.com wrote:
EE I'm personally not a big fan of the setKeyspace()/getKeyspace() idea.
EE Getting rid of the keyspace argument makes sense because the keyspace is
EE the highest (or lowest), level of the data-model so its implicit that
On Tue, 2009-12-01 at 15:38 -0600, Ted Zlatanov wrote:
On Tue, 01 Dec 2009 14:23:47 -0600 Eric Evans eev...@rackspace.com wrote:
EE I'm personally not a big fan of the setKeyspace()/getKeyspace() idea.
EE Getting rid of the keyspace argument makes sense because the keyspace is
EE the
2009/12/1 Ted Zlatanov t...@lifelogs.com:
I disagree, why would you want to forbid switching the keyspace? That's
turning off a currently working feature. Also, connections are not
free, especially across WAN links.
It's a currently working feature that (a) only exists in the first
place
[mailto:n...@ger.gmane.org] On Behalf Of Ted Zlatanov
Sent: November 24, 2009 5:24 PM
To: cassandra-user@incubator.apache.org
Subject: Re: Cassandra access control
Looks like I could use:
PAM auth: http://jpam.sourceforge.net/
LDAP/AD auth: http://www.openldap.org/jldap/
The first is definitely OK
Looks like I could use:
PAM auth: http://jpam.sourceforge.net/
LDAP/AD auth: http://www.openldap.org/jldap/
The first is definitely OK (Apache license), but I'm not sure about the
second one (OpenLDAP public license). Looks BSDish to me. It claims to
support Windows auth and is officially
sysauth says it is GPL v2 (also not compatible)
2009/11/23 Ted Zlatanov t...@lifelogs.com:
On Fri, 20 Nov 2009 15:22:07 -0600 Jonathan Ellis jbel...@gmail.com wrote:
JE Kasai is LGPL, and thus not compatible w/ Cassandra. (See
JE http://www.apache.org/legal/3party.html)
How annoying, it
On Mon, 23 Nov 2009 12:22:37 -0600 Jonathan Ellis jbel...@gmail.com wrote:
JE sysauth says it is GPL v2 (also not compatible)
Hmm. I guess I have to reimplement SysAuth. At least the code is not
terribly complicated, but it's a shame to reinvent the cart and the wheel.
Ted
On Thu, 12 Nov 2009 12:09:19 -0600 Ted Zlatanov t...@lifelogs.com wrote:
TZ I created an issue:
TZ https://issues.apache.org/jira/browse/CASSANDRA-547
TZ and will post updates there as needed. This is stage 1, meaning this is
TZ the 0.5 work that will keep the old API. Stage 2 will remove
Kasai is LGPL, and thus not compatible w/ Cassandra. (See
http://www.apache.org/legal/3party.html)
2009/11/20 Ted Zlatanov t...@lifelogs.com:
On Thu, 12 Nov 2009 12:09:19 -0600 Ted Zlatanov t...@lifelogs.com wrote:
TZ I created an issue:
TZ
On Wed, 11 Nov 2009 16:14:09 -0800 Anthony Molinaro
antho...@alumni.caltech.edu wrote:
AM How will authentication work with non-java clients? I don't think thrift
AM itself has authentication built in, and it sounds like a java library is
AM being proposed for the guts. Will it still be
2009/11/12 Ted Zlatanov t...@lifelogs.com:
On Wed, 11 Nov 2009 16:14:09 -0800 Anthony Molinaro
antho...@alumni.caltech.edu wrote:
AM How will authentication work with non-java clients? I don't think thrift
AM itself has authentication built in, and it sounds like a java library is
AM being
On Wed, 11 Nov 2009 14:59:04 -0800 Coe, Robin robin@bluecoat.com wrote:
CR Java's policy manager controls access to environment variables and
CR code execution. All a JAAS service provides is a hook to pass a
CR user's principal to the security manager. So, the only
CR authorization you
On Nov 12, 2009, at 9:12 AM, Jonathan Ellis wrote:
2009/11/12 Ted Zlatanov t...@lifelogs.com:
On Wed, 11 Nov 2009 16:14:09 -0800 Anthony Molinaro antho...@alumni.caltech.edu
wrote:
The client will login with a MapString,String of login tokens and
get
an auth token (probably a String
On Nov 12, 2009, at 10:06 AM, Jonathan Ellis wrote:
2009/11/12 Ted Zlatanov t...@lifelogs.com:
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
+1
It's not a lot of complexity and it doesn't throw sticks into frameworks
that may model a conventional table as a keyspace.
Thorsten
Jonathan Mischo wrote:
Conditional +1 here:
+1
IF the Keyspace parameter is optional in 0.6 forward, but not
completely eliminated
AND IF login() has
Conditional +1 here:
+1
IF the Keyspace parameter is optional in 0.6 forward, but not
completely eliminated
AND IF login() has an optional param for keyspace
AND IF the backend stores a list of keyspaces you're authorized to
access once you're authenticated if you don't specify a single
+1
2009/11/12 Ted Zlatanov t...@lifelogs.com:
On Thu, 12 Nov 2009 10:06:02 -0600 Jonathan Ellis jbel...@gmail.com wrote:
JE 2009/11/12 Ted Zlatanov t...@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
On Thu, 12 Nov 2009 10:23:21 -0600 Jonathan Mischo jmis...@quagility.com
wrote:
JM The problem I see with this is that you can't have a single connection
JM accessing multiple keyspaces at once. I can think of some cases where
JM having a single connection access and differentiate between two
frameworks that do that should be shot.
On Thu, Nov 12, 2009 at 10:48 AM, Thorsten von Eicken
t...@rightscale.com wrote:
+1
It's not a lot of complexity and it doesn't throw sticks into frameworks
that may model a conventional table as a keyspace.
Thorsten
Jonathan Mischo wrote:
On Thu, 12 Nov 2009 10:49:59 -0600 Jonathan Ellis jbel...@gmail.com wrote:
JE On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo jmis...@quagility.com
wrote:
Let's keep it simple. Forcing multiple connections from a purely
hypothetical use case is a no-brainer tradeoff. Connections are not
now for a move to a new
building. I am happy to provide any advice I can, though, regardless.
Robin.
-Original Message-
From: news [mailto:n...@ger.gmane.org] On Behalf Of Ted Zlatanov
Sent: November 12, 2009 11:35 AM
To: cassandra-user@incubator.apache.org
Subject: Re: Cassandra access
works for me.
2009/11/12 Ted Zlatanov t...@lifelogs.com:
On Thu, 12 Nov 2009 10:49:59 -0600 Jonathan Ellis jbel...@gmail.com wrote:
JE On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo jmis...@quagility.com
wrote:
Let's keep it simple. Forcing multiple connections from a purely
On Thu, 12 Nov 2009 10:59:52 -0600 Ted Zlatanov t...@lifelogs.com wrote:
TZ On Thu, 12 Nov 2009 10:49:59 -0600 Jonathan Ellis jbel...@gmail.com
wrote:
JE On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo jmis...@quagility.com
wrote:
Let's keep it simple. Forcing multiple connections from a
on behalf of Ted Zlatanov
Sent: Thu 12/11/2009 08:59
To: cassandra-user@incubator.apache.org
Subject: Re: Cassandra access control
On Thu, 12 Nov 2009 10:49:59 -0600 Jonathan Ellis jbel...@gmail.com wrote:
JE On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo jmis...@quagility.com
wrote:
Let's keep
41 matches
Mail list logo
