You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Ted Zlatanov <tz...@lifelogs.com> on 2009/11/12 16:51:58 UTC
Re: Cassandra access control
On Thu, 12 Nov 2009 09:12:56 -0600 Jonathan Ellis <jb...@gmail.com> wrote:
JE> 2009/11/12 Ted Zlatanov <tz...@lifelogs.com>:
>> On Wed, 11 Nov 2009 16:14:09 -0800 Anthony Molinaro <an...@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 possible to connect from
AM> a non-java client or will the thrift interface be deprecated?
>>
>> The client will login with a Map<String,String> of login tokens and get
>> an auth token (probably a String containing a UUID) back. The token
>> will be valid for the duration of the client connection and will grant
>> access to a single keyspace. Effectively, the token replaces the old
>> Keyspace argument in all Thrift API calls.
JE> I'd really prefer to just keep that around in a threadlocal. There's
JE> no reason for a client to continue passing a token w/ each call that
JE> the server already knows.
OK.
>> I am thinking of allowing dual operation where if you pass a keyspace
>> name without login, it works on servers that don't have authentication
>> enabled.
JE> The default should definitely be, "don't break people who don't need
JE> the new feature more than necessary." So 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. You want to keep allowing multiple keyspaces? That would leave
the existing API intact (only adding a login function) but requires an
extra authorization check every time a keyspace is given. Do we expire
authorizations after a certain time?
Ted
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
frameworks that do that should be shot.
On Thu, Nov 12, 2009 at 10:48 AM, Thorsten von Eicken
<tv...@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:
>>
>> 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 keyspace you're
>> authenticating to (this should be very simple and lightweight)
>>
>> Does that all make sense? The second note above is probably not strictly
>> necessary for 0.5, but it streamlines the third note, since in 90+% of
>> cases, you'll be working with a single keyspace and can save overhead by
>> just authenticating to that single keyspace.
>>
>> On Nov 12, 2009, at 10:20 AM, Ted Zlatanov wrote:
>>
>>> On Thu, 12 Nov 2009 10:06:02 -0600 Jonathan Ellis <jb...@gmail.com>
>>> wrote:
>>>
>>> JE> 2009/11/12 Ted Zlatanov <tz...@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 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. You want to keep allowing multiple keyspaces? That would leave
>>>>> the existing API intact (only adding a login function) but requires an
>>>>> extra authorization check every time a keyspace is given. Do we expire
>>>>> 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
>>> this
>>> JE> in 0.5). But 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. If 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). Otherwise, no check is done. This keeps
>>> 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. login() will
>>> be required to specify the Keyspace regardless of whether authentication
>>> is done or not. The only expected security exception here comes from
>>> login(). Once 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
>>> places in 0.5
>>>
>>> - implement that interface: provide a XML backend and a LDAP backend (no
>>> JAAS). Also, a AllowAll backend will be provided.
>>>
>>> - add the configuration file stanza to point to the
>>> authentication+authorization module to be used. Make AllowAll the
>>> default auth backend there.
>>>
>>> - document all the changes
>>>
>>> Thanks
>>> Ted
>>>
>>
>
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
+1
2009/11/12 Ted Zlatanov <tz...@lifelogs.com>:
> On Thu, 12 Nov 2009 10:06:02 -0600 Jonathan Ellis <jb...@gmail.com> wrote:
>
> JE> 2009/11/12 Ted Zlatanov <tz...@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 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. You want to keep allowing multiple keyspaces? That would leave
>>> the existing API intact (only adding a login function) but requires an
>>> extra authorization check every time a keyspace is given. Do we expire
>>> 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 this
> JE> in 0.5). But 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. If 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). Otherwise, no check is done. This keeps
> 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. login() will
> be required to specify the Keyspace regardless of whether authentication
> is done or not. The only expected security exception here comes from
> login(). Once 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
> places in 0.5
>
> - implement that interface: provide a XML backend and a LDAP backend (no
> JAAS). Also, a AllowAll backend will be provided.
>
> - add the configuration file stanza to point to the
> authentication+authorization module to be used. Make AllowAll the
> default auth backend there.
>
> - document all the changes
>
> Thanks
> Ted
>
>
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
Yeah, it does suck. :-|
2009/11/23 Ted Zlatanov <tz...@lifelogs.com>:
> On Mon, 23 Nov 2009 12:22:37 -0600 Jonathan Ellis <jb...@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
>
>
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Mon, 23 Nov 2009 12:22:37 -0600 Jonathan Ellis <jb...@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
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
sysauth says it is GPL v2 (also not compatible)
2009/11/23 Ted Zlatanov <tz...@lifelogs.com>:
> On Fri, 20 Nov 2009 15:22:07 -0600 Jonathan Ellis <jb...@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 was exactly what I needed. I hate reinventing the
> wheel. I can at least use SysAuth
> (www.scribblin.gs/software/sysauth.html), I think.
>
> Ted
>
>
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Wed, 25 Nov 2009 09:05:51 -0800 "Coe, Robin" <ro...@bluecoat.com> wrote:
CR> If all you want to perform is a simple bind to an LDAP service, then
CR> why use either? JPam uses JAAS under the covers and jldap is a full
CR> API for managing a depot. Neither solution looks particularly
CR> optimized.
I thought (from the docs) that JPam was like SysAuth, an actual library
to talk to PAM instead of a JAAS overlay. JAAS as we discussed only
works for the user that's running Cassandra, so it's not a good option.
jldap seems (again, from the docs) to support secure LDAP better than
JNDI (see below).
CR> If ldap integration is a must-have, then why not just use JNDI?
CR> Create a singleton factory that sets up the environment, including a
CR> connection pool, to create an initial context. Then, use that to
CR> create a per-Thrift connection binding context, with credentials
CR> passed in from the client?
I considered that too. Based on
http://forums.sun.com/thread.jspa?threadID=581425&tstart=45 secure LDAP
is a pain to set up with JNDI and I'm pretty sure most LDAP users will
want it. What's your experience with that?
CR> However, I still think the simplest, fastest solution is to use a
CR> Cassandra-managed user realm, similar to RDBMS systems. That keeps
CR> the connection opening phase within the Cassandra engine and isn't
CR> susceptible to the service being unavailable. As well, if Cassandra
CR> manages the user realm on a per-keyspace basis, then authentication
CR> and authorization can be performed simultaneously and the keyspace
CR> argument can be dropped from the Thrift API calls.
I'll provide a mechanism to give a user name and a password directly in
the configuration per keyspace as you suggest. There will also be an
AllowAll backend to allow any access. See
https://issues.apache.org/jira/browse/CASSANDRA-547
The password will probably be MD5 hashed in transit (with some salt).
MD5 is significantly faster than the more secure alternatives and I
think, when salted, it's more than reasonably secure for one-way
hashing. I'm not a cryptography expert, though, so I'm open to
suggestions.
I think Jonathan agreed with me that a later version of the Thrift API
will drop the keyspace argument in favor of a setKeyspace() call. For
now (phase 1) the two will coexist.
CR> Configuring Cassandra to handle LDAP binding will require
CR> configuring the connection url, protocol, search scope, base DN,
CR> keystore file, etc. And of course, if Cassandra has LDAP
CR> integration, it should probably offer other authentication service
CR> support, like RADIUS and TACACS+, etc. It's a can of worms, to be
CR> sure.
If it was easy it would have been done already :) I appreciate your
help and we'll get this done soon. I've spent a lot of time on
libraries, unfortunately.
CR> While on the topic of authentication, I still like the idea of
CR> opening a connection with credentials, as opposed to requiring a
CR> separate transaction to login. That's an unnecessary round trip. I
CR> don't see why an overloaded method to connect is a bad thing,
CR> especially when the anonymous connection will eventually be
CR> deprecated. At least, I assume it will be deprecated by the time
CR> Cassandra has a fully fleshed out authentication realm?
We can do that as one API call, as long as internally Cassandra splits
it in two. Also the user has to know that the method could return more
than one kind of exception (connection and authentication/authorization
problems can happen in one call).
The anonymous connection will simply map to the AllowAll backend I
mentioned. Any username and password will work. There will be no way
to establish a connection or set a keyspace without using a backend, so
in that sense anonymous connects will be deprecated, but they won't go
away.
It should be easy for the user to provide their own backend, similar to
the partitioner approach in Cassandra. There's no reason to block
organizations from implementing their own auth schemes. Cassandra will
simply map a keyspace to a backend and let the backend do all the auth
work.
Ted
RE: Re: Cassandra access control
Posted by "Coe, Robin" <ro...@bluecoat.com>.
If all you want to perform is a simple bind to an LDAP service, then why use either? JPam uses JAAS under the covers and jldap is a full API for managing a depot. Neither solution looks particularly optimized.
If ldap integration is a must-have, then why not just use JNDI? Create a singleton factory that sets up the environment, including a connection pool, to create an initial context. Then, use that to create a per-Thrift connection binding context, with credentials passed in from the client?
However, I still think the simplest, fastest solution is to use a Cassandra-managed user realm, similar to RDBMS systems. That keeps the connection opening phase within the Cassandra engine and isn't susceptible to the service being unavailable. As well, if Cassandra manages the user realm on a per-keyspace basis, then authentication and authorization can be performed simultaneously and the keyspace argument can be dropped from the Thrift API calls.
Configuring Cassandra to handle LDAP binding will require configuring the connection url, protocol, search scope, base DN, keystore file, etc. And of course, if Cassandra has LDAP integration, it should probably offer other authentication service support, like RADIUS and TACACS+, etc. It's a can of worms, to be sure.
While on the topic of authentication, I still like the idea of opening a connection with credentials, as opposed to requiring a separate transaction to login. That's an unnecessary round trip. I don't see why an overloaded method to connect is a bad thing, especially when the anonymous connection will eventually be deprecated. At least, I assume it will be deprecated by the time Cassandra has a fully fleshed out authentication realm?
Robin.
-----Original Message-----
From: news [mailto:news@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 (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 provided by the OpenLDAP project.
Has anyone used it?
Thanks
Ted
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
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 provided by the OpenLDAP project.
Has anyone used it?
Thanks
Ted
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Fri, 20 Nov 2009 15:22:07 -0600 Jonathan Ellis <jb...@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 was exactly what I needed. I hate reinventing the
wheel. I can at least use SysAuth
(www.scribblin.gs/software/sysauth.html), I think.
Ted
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
Kasai is LGPL, and thus not compatible w/ Cassandra. (See
http://www.apache.org/legal/3party.html)
2009/11/20 Ted Zlatanov <tz...@lifelogs.com>:
> On Thu, 12 Nov 2009 12:09:19 -0600 Ted Zlatanov <tz...@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 the
> TZ> Keyspace parameters from the API so I'll put that work in a different
> TZ> issue, linked to CASSANDRA-547.
>
> I found a good open-source library for auth*:
> http://kasai.manentiasoftware.com/
>
> Has anyone used it? Looking at the source and API docs, it's decent and
> supports several backends out of the box, including MySQL, PostgreSQL,
> and SQL Server (which covers Sybase too). I'd rather use it than put my
> own together :)
>
> It uses http://www.scribblin.gs/software/sysauth.html to provide a PAM
> interface (which can then hook into LDAP/AD/etc. securely); an example
> of SysAuth use with JBoss is at
> http://www.mrchucho.net/2004/12/27/jboss-linux-authentication/
>
> Unless there are any objections I'll use Kasai.
>
> Ted
>
>
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
2009/12/1 Ted Zlatanov <tz...@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 because it was less bad than postponing 0.4 until we could add
something like this auth feature, and (b) is of entirely theoretical
benefit in the sense that nobody who wants to keep it actually has an
app using it, to the best of my knowledge.
Let's correct our error, and only add functionality that we know is
really needed -- and even then, only if the benefit outweighs the
complexity price -- rather than waving our hands and saying "maybe
someone will need it, someday." That way leads to clutter and bloat.
-Jonathan
Re: Cassandra access control
Posted by Jonathan Mischo <jm...@quagility.com>.
+1, it's a good solution to both scenarios, with reduced overhead all
around.
On Nov 12, 2009, at 11:01 AM, Jonathan Ellis wrote:
> works for me.
>
> 2009/11/12 Ted Zlatanov <tz...@lifelogs.com>:
>> On Thu, 12 Nov 2009 10:49:59 -0600 Jonathan Ellis
>> <jb...@gmail.com> wrote:
>>
>> JE> On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo <jmischo@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
>>>>> expensive.
>>
>>>> Even if we can do it sensibly? Connections aren't hugely
>>>> expensive, but
>>>> they're not free, either.
>>
>> JE> I suppose, but if it requires sending a keyspace param w/ each
>> call,
>> JE> then it's not sensible. You waste far more overhead for that
>> in the
>> JE> common case -- serializing, deserializing, checking that it's
>> been
>> JE> authed -- than you gain from not having another connection in the
>> JE> uncommon one.
>>
>> JE> I would be okay with being able to send a 2nd auth call to an
>> existing
>> JE> connection to switch the "current" keyspace, similar to how
>> rdbmses
>> JE> only have one active schema at a time.
>>
>> How about:
>>
>> login(Map<String, String> credentials) throws
>> CassandraAuthenticationSecurityException
>>
>> setKeyspace(String keyspace) throws
>> CassandraAuthorizationSecurityException
>>
>> and then all the existing API calls won't have a Keyspace parameter
>> as
>> previously discussed. This works for everyone, I think, and
>> separates
>> authentication from authorization nicely.
>>
>> Ted
>>
>>
>
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
works for me.
2009/11/12 Ted Zlatanov <tz...@lifelogs.com>:
> On Thu, 12 Nov 2009 10:49:59 -0600 Jonathan Ellis <jb...@gmail.com> wrote:
>
> JE> On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo <jm...@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
>>> > expensive.
>
>>> Even if we can do it sensibly? Connections aren't hugely expensive, but
>>> they're not free, either.
>
> JE> I suppose, but if it requires sending a keyspace param w/ each call,
> JE> then it's not sensible. You waste far more overhead for that in the
> JE> common case -- serializing, deserializing, checking that it's been
> JE> authed -- than you gain from not having another connection in the
> JE> uncommon one.
>
> JE> I would be okay with being able to send a 2nd auth call to an existing
> JE> connection to switch the "current" keyspace, similar to how rdbmses
> JE> only have one active schema at a time.
>
> How about:
>
> login(Map<String, String> credentials) throws CassandraAuthenticationSecurityException
>
> setKeyspace(String keyspace) throws CassandraAuthorizationSecurityException
>
> and then all the existing API calls won't have a Keyspace parameter as
> previously discussed. This works for everyone, I think, and separates
> authentication from authorization nicely.
>
> Ted
>
>
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Wed, 02 Dec 2009 19:13:58 +0000 Bill de hOra <bi...@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" <ro...@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
Re: Cassandra access control
Posted by Bill de hOra <bi...@dehora.net>.
Mark Robson wrote:
> 2009/12/2 Ted Zlatanov <tzz@lifelogs.com <ma...@lifelogs.com>>
>
> OK. So what should the API be? Just one method, as Robin suggested?
>
> void login( Map<String, String> credentials, String keyspace )
> throws AuthenticationException, AuthorizationException
>
> In this model the backend would still have login() and
> setKeyspace()/getKeyspace() separately to distinguish between
> authentication and authorization but the frontend API would merge them.
>
>
> I'd be against moving to a stateful protocol.
Strong agreement. The login method should return an opaque token which
is passed on each call. If that messes up the API, that says more about
Thrift than the auth model.
Bill
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Wed, 2 Dec 2009 15:23:23 -0600 Jonathan Ellis <jb...@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 thought a
vote was sensible. How else can we resolve the debate so I can actually
write some code? I really don't have a preference as I mentioned, I
just want to get the auth code done.
Ted
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
It's really premature to be holding a "vote" based on first-impression opinions.
2009/12/2 Ted Zlatanov <tz...@lifelogs.com>:
> On Wed, 2 Dec 2009 20:54:13 +0000 Mark Robson <ma...@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 need it.
>
> That was my original proposal. Jonathan and Eric disagreed and made
> good arguments against it. Multiple operation modes are more confusing
> IMO.
>
> In the latest proposed version, authentication is off by default: all
> calls go to the AllowAll backend with a negligible overhead. You still
> have to make a login() call but it's effectively a setKeyspace().
>
> I don't think backwards compatibility should limit innovation in a 0.x
> release. The extra complexity is negligible: you just pass an empty
> AuthenticationRequest if you don't need it. From that point on, you
> actually have one less argument (no keyspace) on many Thrift calls.
>
> On Wed, 2 Dec 2009 15:59:40 -0500 Jake Luciani <ja...@gmail.com> wrote:
>
> JL> +1 this is nosql afterall.
>
> I don't think NoSQL == stateless. The two are completely orthogonal.
>
> The vote is 3-3 (Jonathan, Robin, Evan - Mark, Jake, Bill).
>
> Ted
>
>
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Wed, 2 Dec 2009 15:32:35 -0600 Jonathan Ellis <jb...@gmail.com> wrote:
JE> 2009/12/2 Ted Zlatanov <tz...@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 <ee...@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
Re: Cassandra access control
Posted by Anthony Molinaro <an...@alumni.caltech.edu>.
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 are running a chat
server with public rooms and private rooms. Public rooms live in a
keyspace with no authentication, and private rooms each have their
own keyspace with a token (a bit contrived, but you get the idea hopefully).
Users would have unauthenticated access to one keyspace and authenticated
access to others but be able to query both over the same connection.
-Anthony
On Wed, Dec 02, 2009 at 04:43:19PM -0500, Jake Luciani wrote:
> 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 <jb...@gmail.com> wrote:
>
> >What backwards compatibility are you concerned with breaking?
> >
> >Having keyspace be a per-command arg is a bug, not a feature.
> >
> >On Wed, Dec 2, 2009 at 2:54 PM, Mark Robson <ma...@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 extra
> >>complexity for people who don't need it.
> >>
> >>Mark
> >>
--
------------------------------------------------------------------------
Anthony Molinaro <an...@alumni.caltech.edu>
Re: Cassandra access control
Posted by Jake Luciani <ja...@gmail.com>.
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 <jb...@gmail.com> wrote:
> What backwards compatibility are you concerned with breaking?
>
> Having keyspace be a per-command arg is a bug, not a feature.
>
> On Wed, Dec 2, 2009 at 2:54 PM, Mark Robson <ma...@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 extra
>> complexity for people who don't need it.
>>
>> Mark
>>
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
What backwards compatibility are you concerned with breaking?
Having keyspace be a per-command arg is a bug, not a feature.
On Wed, Dec 2, 2009 at 2:54 PM, Mark Robson <ma...@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 extra
> complexity for people who don't need it.
>
> Mark
>
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
2009/12/2 Ted Zlatanov <tz...@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.
That makes no sense whatsoever. Backends can maintain state or not
either way; adding a token you have to pass back makes just adds an
extra layer of mapping token -> real state in the simple case of
token-is-only-valid-per-connection and an unreasonable amount of
complexity if you try to make it valid across more than one.
I'm -1 in the apache veto sense on the token idea.
-Jonathan
Re: Cassandra access control
Posted by Jake Luciani <ja...@gmail.com>.
Got it.
On Dec 2, 2009, at 4:42 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> It doesn't have to be the outside world, just apps from different
> groups. Which is the whole (or at least, a major) reason we added
> multiple keyspaces.
>
> On Wed, Dec 2, 2009 at 3:38 PM, Jake Luciani <ja...@gmail.com> wrote:
>> If there is a use case to open a Cassandra cluster to the world
>> then I
>> agree.
>>
>> Sent from my iPhone
>>
>> On Dec 2, 2009, at 4:24 PM, "Coe, Robin" <ro...@bluecoat.com>
>> wrote:
>>
>>> NoSQL doesn't mean no security. A production database engine has to
>>> protect its data. The trick is to make the auth framework fast
>>> enough
>>> that it doesn't adversely affect performance and robust enough
>>> that an
>>> application requesting data doesn't have to jump through hoops to
>>> get
>>> it.
>>>
>>> -----Original Message-----
>>> From: Jake Luciani [mailto:jakers@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 <ma...@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 extra
>>>> complexity for people who don't need it.
>>>>
>>>> Mark
>>
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
It doesn't have to be the outside world, just apps from different
groups. Which is the whole (or at least, a major) reason we added
multiple keyspaces.
On Wed, Dec 2, 2009 at 3:38 PM, Jake Luciani <ja...@gmail.com> wrote:
> If there is a use case to open a Cassandra cluster to the world then I
> agree.
>
> Sent from my iPhone
>
> On Dec 2, 2009, at 4:24 PM, "Coe, Robin" <ro...@bluecoat.com> wrote:
>
>> NoSQL doesn't mean no security. A production database engine has to
>> protect its data. The trick is to make the auth framework fast enough
>> that it doesn't adversely affect performance and robust enough that an
>> application requesting data doesn't have to jump through hoops to get
>> it.
>>
>> -----Original Message-----
>> From: Jake Luciani [mailto:jakers@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 <ma...@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 extra
>>> complexity for people who don't need it.
>>>
>>> Mark
>
RE: Cassandra access control
Posted by "Coe, Robin" <ro...@bluecoat.com>.
Public IPs and ports make it so.
-----Original Message-----
From: Jake Luciani [mailto:jakers@gmail.com]
Sent: December 2, 2009 4:39 PM
To: cassandra-user@incubator.apache.org
Subject: Re: Cassandra access control
If there is a use case to open a Cassandra cluster to the world then I
agree.
Sent from my iPhone
On Dec 2, 2009, at 4:24 PM, "Coe, Robin" <ro...@bluecoat.com> wrote:
> NoSQL doesn't mean no security. A production database engine has to
> protect its data. The trick is to make the auth framework fast enough
> that it doesn't adversely affect performance and robust enough that an
> application requesting data doesn't have to jump through hoops to get
> it.
>
> -----Original Message-----
> From: Jake Luciani [mailto:jakers@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 <ma...@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 extra
>> complexity for people who don't need it.
>>
>> Mark
Re: Cassandra access control
Posted by Jake Luciani <ja...@gmail.com>.
If there is a use case to open a Cassandra cluster to the world then I
agree.
Sent from my iPhone
On Dec 2, 2009, at 4:24 PM, "Coe, Robin" <ro...@bluecoat.com> wrote:
> NoSQL doesn't mean no security. A production database engine has to
> protect its data. The trick is to make the auth framework fast enough
> that it doesn't adversely affect performance and robust enough that an
> application requesting data doesn't have to jump through hoops to get
> it.
>
> -----Original Message-----
> From: Jake Luciani [mailto:jakers@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 <ma...@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 extra
>> complexity for people who don't need it.
>>
>> Mark
RE: Cassandra access control
Posted by "Coe, Robin" <ro...@bluecoat.com>.
NoSQL doesn't mean no security. A production database engine has to
protect its data. The trick is to make the auth framework fast enough
that it doesn't adversely affect performance and robust enough that an
application requesting data doesn't have to jump through hoops to get
it.
-----Original Message-----
From: Jake Luciani [mailto:jakers@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 <ma...@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 extra
> complexity for people who don't need it.
>
> Mark
Re: Cassandra access control
Posted by Jake Luciani <ja...@gmail.com>.
+1 this is nosql afterall.
Sent from my iPhone
On Dec 2, 2009, at 3:54 PM, Mark Robson <ma...@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 extra
> complexity for people who don't need it.
>
> Mark
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Wed, 2 Dec 2009 20:54:13 +0000 Mark Robson <ma...@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 need it.
That was my original proposal. Jonathan and Eric disagreed and made
good arguments against it. Multiple operation modes are more confusing
IMO.
In the latest proposed version, authentication is off by default: all
calls go to the AllowAll backend with a negligible overhead. You still
have to make a login() call but it's effectively a setKeyspace().
I don't think backwards compatibility should limit innovation in a 0.x
release. The extra complexity is negligible: you just pass an empty
AuthenticationRequest if you don't need it. From that point on, you
actually have one less argument (no keyspace) on many Thrift calls.
On Wed, 2 Dec 2009 15:59:40 -0500 Jake Luciani <ja...@gmail.com> wrote:
JL> +1 this is nosql afterall.
I don't think NoSQL == stateless. The two are completely orthogonal.
The vote is 3-3 (Jonathan, Robin, Evan - Mark, Jake, Bill).
Ted
Re: Cassandra access control
Posted by Mark Robson <ma...@gmail.com>.
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
Re: Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
On Wed, Dec 2, 2009 at 1:59 PM, Coe, Robin <ro...@bluecoat.com> wrote:
> Once a connection is opened with credentials, then as long as I hold that connection open, I shouldn't need to pass auth checks with every transaction.
Exactly. This isn't http where we are opening a new connection with
each call. (If you are, You're Doing It Wrong. :)
-Jonathan
Re: Cassandra access control
Posted by Eric Evans <ee...@rackspace.com>.
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 provide fall-back logic
> to
> EE> authenticate with credentials, if the token fails. So, tokens
> would
> EE> probably just add complexity without much benefit."
>
> 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.
If not for SSO via shared-state between nodes, then for what? Can you
give a tangible example of "when it makes sense to do so"? Are you sure
this isn't YAGNI?
--
Eric Evans
eevans@rackspace.com
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Wed, 02 Dec 2009 14:35:09 -0600 Eric Evans <ee...@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 <ee...@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 and allowing for auth
>> backends to modify the authentication request:
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 provide fall-back logic to
EE> authenticate with credentials, if the token fails. So, tokens would
EE> probably just add complexity without much benefit."
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.
Ted
Re: Cassandra access control
Posted by Eric Evans <ee...@rackspace.com>.
On Wed, 2009-12-02 at 14:27 -0600, Ted Zlatanov wrote:
> On Wed, 02 Dec 2009 14:14:53 -0600 Eric Evans <ee...@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 and allowing for auth
> backends to modify the authentication request:
Let's not do that; as Robin pointed out...
"...there's no way to ensure immediate consistency of tokens across all
nodes, it's probably not worth the effort of making Cassandra "token
aware", since an application would have to provide fall-back logic to
authenticate with credentials, if the token fails. So, tokens would
probably just add complexity without much benefit."
--
Eric Evans
eevans@rackspace.com
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Wed, 02 Dec 2009 14:14:53 -0600 Eric Evans <ee...@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 and allowing for auth
backends to modify the authentication request:
struct AuthenticationRequest {
1: optional map<string, string> credentials,
}
service Cassandra {
...
# authentication and authorization. Returns the authentication request (never null) with any auth tokens that may have been created by the auth backends
AuthenticationRequest login(1: required string keyspace,
2: required AuthenticationRequest auth_request)
throws (1:AuthenticationException aux, 2: AuthorizationException azx),
...
}
Ted
Re: Cassandra access control
Posted by Eric Evans <ee...@rackspace.com>.
On Wed, 2009-12-02 at 13:28 -0600, Ted Zlatanov wrote:
>
> struct AuthenticationRequest {
> 1: required map<string, string> credentials,
> }
>
> service Cassandra {
> ...
> void login(1: required string keyspace,
> 2: optional AuthenticationRequest auth_request)
> throws (1:AuthenticationException aux, 2:
> AuthorizationException azx),
> ...
> }
Did you maybe mean...?
struct AuthenticationRequest {
1: optional map<string, string> credentials,
}
service Cassandra {
...
void login(1:required string keyspace,
2:required AuthenticationRequest auth_request)
throws (1:AuthenticationException aux, 2:AuthorizationException azx),
...
}
i.e. AuthenticationRequest required for the method (has to be), but the
map is optional?
--
Eric Evans
eevans@rackspace.com
RE: Re: Cassandra access control
Posted by "Coe, Robin" <ro...@bluecoat.com>.
Once a connection is opened with credentials, then as long as I hold that connection open, I shouldn't need to pass auth checks with every transaction.
On the other hand, if there was a way to use a token in lieu of credentials, to provide SSO capabilities to any node, then I could see their use. Checking whether a token exists in a local collection would be much faster than having to pass through an authentication/authorization framework. However, as there's no way to ensure immediate consistency of tokens across all nodes, it's probably not worth the effort of making Cassandra "token aware", since an application would have to provide fall-back logic to authenticate with credentials, if the token fails. So, tokens would probably just add complexity without much benefit.
Robin.
-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Ted Zlatanov
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 +0000 Mark Robson <ma...@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 it will
work fine either way. Eric and Jonathan are definitely on the stateful
side so it's 2-1 right now. I think Robin is also on the stateful side
from his earlier notes so it may be 3-1.
On Wed, 02 Dec 2009 11:59:56 -0600 Eric Evans <ee...@rackspace.com> wrote:
EE> I'm thinking...
EE> void login(1:required string keyspace, 2:optional map<string, string>
EE> authentication) throws AuthenticationException, AuthorizationException
EE> You're always going to want the keyspace supplied, but depending on how
EE> the cluster is configured, you may not need anything else (so make the
EE> map the second argument, and make it optional).
I was going to use an empty map to signify no credentials. Optional
works just as well. Thus the Thrift definition is:
# invalid authentication request (user does not exist or credentials invalid)
exception AuthenticationException {
1: required string why
}
# invalid authorization request (user does not have access to keyspace)
exception AuthorizationException {
1: required string why
}
struct AuthenticationRequest {
1: required map<string, string> credentials,
}
service Cassandra {
...
void login(1: required string keyspace,
2: optional AuthenticationRequest auth_request)
throws (1:AuthenticationException aux, 2: AuthorizationException azx),
...
}
Ted
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Wed, 2 Dec 2009 15:13:11 +0000 Mark Robson <ma...@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 it will
work fine either way. Eric and Jonathan are definitely on the stateful
side so it's 2-1 right now. I think Robin is also on the stateful side
from his earlier notes so it may be 3-1.
On Wed, 02 Dec 2009 11:59:56 -0600 Eric Evans <ee...@rackspace.com> wrote:
EE> I'm thinking...
EE> void login(1:required string keyspace, 2:optional map<string, string>
EE> authentication) throws AuthenticationException, AuthorizationException
EE> You're always going to want the keyspace supplied, but depending on how
EE> the cluster is configured, you may not need anything else (so make the
EE> map the second argument, and make it optional).
I was going to use an empty map to signify no credentials. Optional
works just as well. Thus the Thrift definition is:
# invalid authentication request (user does not exist or credentials invalid)
exception AuthenticationException {
1: required string why
}
# invalid authorization request (user does not have access to keyspace)
exception AuthorizationException {
1: required string why
}
struct AuthenticationRequest {
1: required map<string, string> credentials,
}
service Cassandra {
...
void login(1: required string keyspace,
2: optional AuthenticationRequest auth_request)
throws (1:AuthenticationException aux, 2: AuthorizationException azx),
...
}
Ted
Re: Cassandra access control
Posted by Mark Robson <ma...@gmail.com>.
2009/12/2 Ted Zlatanov <tz...@lifelogs.com>
> OK. So what should the API be? Just one method, as Robin suggested?
>
> void login( Map<String, String> credentials, String keyspace )
> throws AuthenticationException, AuthorizationException
>
> In this model the backend would still have login() and
> setKeyspace()/getKeyspace() separately to distinguish between
> authentication and authorization but the frontend API would merge them.
>
I'd be against moving to a stateful protocol.
Currently there isn't any per-connection state held by the API (correct me
someone, if I'm wrong), which means you can transparently reconnect (perhaps
to a different server) on error and retry (updates are always safely
repeatable in Cassandra without any bad effects, right?)
Adding a session state means that the application would need to handle
reconnection at a higher level.
Given that only a small proportion of the Cassandra users are likely to want
authentication (immediately), why not leave the keyspace parameter in all
existing methods, but allow the server to throw a AuthenticationException if
you aren't authorised for that keyspace (yet).
Then applications which need to authentication wouldn't need to change.
Mark
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Thu, 12 Nov 2009 12:09:19 -0600 Ted Zlatanov <tz...@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 the
TZ> Keyspace parameters from the API so I'll put that work in a different
TZ> issue, linked to CASSANDRA-547.
I found a good open-source library for auth*:
http://kasai.manentiasoftware.com/
Has anyone used it? Looking at the source and API docs, it's decent and
supports several backends out of the box, including MySQL, PostgreSQL,
and SQL Server (which covers Sybase too). I'd rather use it than put my
own together :)
It uses http://www.scribblin.gs/software/sysauth.html to provide a PAM
interface (which can then hook into LDAP/AD/etc. securely); an example
of SysAuth use with JBoss is at
http://www.mrchucho.net/2004/12/27/jboss-linux-authentication/
Unless there are any objections I'll use Kasai.
Ted
Re: Cassandra access control
Posted by Eric Evans <ee...@rackspace.com>.
On Wed, 2009-12-02 at 08:52 -0600, Ted Zlatanov wrote:
> On Tue, 01 Dec 2009 16:58:50 -0600 Eric Evans <ee...@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 across WAN links.
>
> EE> Because it makes a mess out of an API that already confuses
> people. And
> EE> again, I posit that this is a corner case, something that very few
> EE> people will actually want to do. We should be optimizing for the
> common
> EE> case.
>
> On Tue, 1 Dec 2009 17:13:24 -0600 Jonathan Ellis <jb...@gmail.com>
> wrote:
>
> JE> It's a currently working feature that (a) only exists in the first
> JE> place because it was less bad than postponing 0.4 until we could
> add
> JE> something like this auth feature, and (b) is of entirely
> theoretical
> JE> benefit in the sense that nobody who wants to keep it actually has
> an
> JE> app using it, to the best of my knowledge.
>
> JE> Let's correct our error, and only add functionality that we know
> is
> JE> really needed -- and even then, only if the benefit outweighs the
> JE> complexity price -- rather than waving our hands and saying "maybe
> JE> someone will need it, someday." That way leads to clutter and
> bloat.
>
> OK. So what should the API be? Just one method, as Robin suggested?
>
> void login( Map<String, String> credentials, String keyspace )
> throws AuthenticationException, AuthorizationException
I'm thinking...
void login(1:required string keyspace, 2:optional map<string, string>
authentication) throws AuthenticationException, AuthorizationException
You're always going to want the keyspace supplied, but depending on how
the cluster is configured, you may not need anything else (so make the
map the second argument, and make it optional).
> This means the keyspace parameter will be removed from all the current
> Thrift API calls and application will need to remember what keyspace
> they requested. It will definitely not make 0.5.
Right, but I think that's for the best anyway though.
--
Eric Evans
eevans@rackspace.com
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Tue, 01 Dec 2009 16:58:50 -0600 Eric Evans <ee...@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 across WAN links.
EE> Because it makes a mess out of an API that already confuses people. And
EE> again, I posit that this is a corner case, something that very few
EE> people will actually want to do. We should be optimizing for the common
EE> case.
On Tue, 1 Dec 2009 17:13:24 -0600 Jonathan Ellis <jb...@gmail.com> wrote:
JE> It's a currently working feature that (a) only exists in the first
JE> place because it was less bad than postponing 0.4 until we could add
JE> something like this auth feature, and (b) is of entirely theoretical
JE> benefit in the sense that nobody who wants to keep it actually has an
JE> app using it, to the best of my knowledge.
JE> Let's correct our error, and only add functionality that we know is
JE> really needed -- and even then, only if the benefit outweighs the
JE> complexity price -- rather than waving our hands and saying "maybe
JE> someone will need it, someday." That way leads to clutter and bloat.
OK. So what should the API be? Just one method, as Robin suggested?
void login( Map<String, String> credentials, String keyspace )
throws AuthenticationException, AuthorizationException
In this model the backend would still have login() and
setKeyspace()/getKeyspace() separately to distinguish between
authentication and authorization but the frontend API would merge them.
This means the keyspace parameter will be removed from all the current
Thrift API calls and application will need to remember what keyspace
they requested. It will definitely not make 0.5.
Let me know if this is OK and I'll prepare a new patch.
Thanks
Ted
Re: Cassandra access control
Posted by Eric Evans <ee...@rackspace.com>.
On Tue, 2009-12-01 at 15:38 -0600, Ted Zlatanov wrote:
> On Tue, 01 Dec 2009 14:23:47 -0600 Eric Evans <ee...@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 an
> EE> application need only talk to one. If removing that argument makes sense
> EE> (and I think it does), then we should just do that. Accessing more than
> EE> one keyspace is a corner case IMO, but its one that can be accommodated
> EE> by opening another connection.
>
> 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.
Because it makes a mess out of an API that already confuses people. And
again, I posit that this is a corner case, something that very few
people will actually want to do. We should be optimizing for the common
case.
--
Eric Evans
eevans@rackspace.com
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Tue, 01 Dec 2009 14:23:47 -0600 Eric Evans <ee...@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 an
EE> application need only talk to one. If removing that argument makes sense
EE> (and I think it does), then we should just do that. Accessing more than
EE> one keyspace is a corner case IMO, but its one that can be accommodated
EE> by opening another connection.
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.
EE> Also, I don't know how others feel, but I'm not comfortable committing
EE> anything that would be a candidate for 0.5 that isn't more fully baked
EE> at this point. So I'd rather see something that is at least minimally
EE> useful targeted for 0.5+1
I'm not dying to get into 0.5. My goal is to get a good API in place.
First thing is to agree on the API, then I can implement it. My first
attempt simply keeps everything working like it did before by using the
AllowAll authenticator. The next step is to put in configuration
support to use a different authenticator and provide a few basic ones as
we discussed (PAM and LDAP probably). It's unlikely we'll make 0.5
considering its current state is close to release IIUC.
If we miss 0.5 I'll take out the backwards compatibility API that still
allows the keyspace argument for a few of the calls. It's not a big
deal to do so.
Ted
Re: Cassandra access control
Posted by Eric Evans <ee...@rackspace.com>.
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 the Thrift interface:
>
> # invalid authentication request (user does not exist or credentials
> invalid)
> exception AuthenticationException {
> 1: required string why
> }
>
> # invalid authorization request (user does not have access to
> keyspace)
> exception AuthorizationException {
> 1: required string why
> }
>
> ...
>
> struct AuthenticationRequest {
> 1: required map<string, string> credentials,
> }
>
> service Cassandra {
> # auth methods
> # authentication
> void login(1:required AuthenticationRequest auth_request) throws
> (1:AuthenticationException aux),
>
> # authorization
> void setKeyspace(1:required string keyspace) throws
> (1:AuthorizationException azx),
> string getKeyspace(),
I'm personally not a big fan of the setKeyspace()/getKeyspace() idea.
Getting rid of the keyspace argument makes sense because the keyspace is
the highest (or lowest), level of the data-model so its implicit that an
application need only talk to one. If removing that argument makes sense
(and I think it does), then we should just do that. Accessing more than
one keyspace is a corner case IMO, but its one that can be accommodated
by opening another connection.
Also, I don't know how others feel, but I'm not comfortable committing
anything that would be a candidate for 0.5 that isn't more fully baked
at this point. So I'd rather see something that is at least minimally
useful targeted for 0.5+1
--
Eric Evans
eevans@rackspace.com
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
I posted the first attempt (with a default AllowAll backend) as a patch:
https://issues.apache.org/jira/browse/CASSANDRA-547
Important changes in the Thrift interface:
# invalid authentication request (user does not exist or credentials invalid)
exception AuthenticationException {
1: required string why
}
# invalid authorization request (user does not have access to keyspace)
exception AuthorizationException {
1: required string why
}
...
struct AuthenticationRequest {
1: required map<string, string> credentials,
}
service Cassandra {
# auth methods
# authentication
void login(1:required AuthenticationRequest auth_request) throws (1:AuthenticationException aux),
# authorization
void setKeyspace(1:required string keyspace) throws (1:AuthorizationException azx),
string getKeyspace(),
...
When I generated the Java files, I got compilation errors on some
unrelated stuff but the auth code will at least compile, and should be
100% backwards compatible as discussed. I only looked for the string
"keyspace" so I may have missed some places. Please let me know what
you think.
Thanks
Ted
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Thu, 12 Nov 2009 10:59:52 -0600 Ted Zlatanov <tz...@lifelogs.com> wrote:
TZ> On Thu, 12 Nov 2009 10:49:59 -0600 Jonathan Ellis <jb...@gmail.com> wrote:
JE> On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo <jm...@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
>>> > expensive.
>>> Even if we can do it sensibly? Connections aren't hugely expensive, but
>>> they're not free, either.
JE> I suppose, but if it requires sending a keyspace param w/ each call,
JE> then it's not sensible. You waste far more overhead for that in the
JE> common case -- serializing, deserializing, checking that it's been
JE> authed -- than you gain from not having another connection in the
JE> uncommon one.
JE> I would be okay with being able to send a 2nd auth call to an existing
JE> connection to switch the "current" keyspace, similar to how rdbmses
JE> only have one active schema at a time.
TZ> How about:
TZ> login(Map<String, String> credentials) throws CassandraAuthenticationSecurityException
TZ> setKeyspace(String keyspace) throws CassandraAuthorizationSecurityException
TZ> and then all the existing API calls won't have a Keyspace parameter as
TZ> previously discussed. This works for everyone, I think, and separates
TZ> authentication from authorization nicely.
I created an issue:
https://issues.apache.org/jira/browse/CASSANDRA-547
and will post updates there as needed. This is stage 1, meaning this is
the 0.5 work that will keep the old API. Stage 2 will remove the
Keyspace parameters from the API so I'll put that work in a different
issue, linked to CASSANDRA-547.
Thanks
Ted
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Thu, 12 Nov 2009 16:24:11 -0800 "Coe, Robin" <ro...@bluecoat.com> wrote:
CR> Why pass a map of credentials? Why not follow the standard approach
CR> of opening the connection with the credentials, as in tr.open( uid,
CR> passwd )? For now, that can be an overloaded method call that would
CR> leave the existing API as-is.
I would rather start with an unauthenticated connection, which is just
as standard (e.g. the IMAP protocol uses that approach, among many
others). Otherwise you either end up with two open() methods or you
have extra code to handle null or failing credentials in the open()
method, and it has two failure modes. Instead I would like to layer the
functionality: open() is for establishing the connection, login() is for
authenticating, setKeyspace() is for authorization.
UID and password are not the only credentials possible so I left it
open. For example, we could pass tokens or anything else that fits in a
String. I would rather have used Comparable but Thrift doesn't have
that as a basic type :)
Ted
RE: Re: Cassandra access control
Posted by "Coe, Robin" <ro...@bluecoat.com>.
Ted,
Why pass a map of credentials? Why not follow the standard approach of opening the connection with the credentials, as in tr.open( uid, passwd )? For now, that can be an overloaded method call that would leave the existing API as-is.
Robin.
-----Original Message-----
From: news 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 <jb...@gmail.com> wrote:
JE> On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo <jm...@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
>> > expensive.
>> Even if we can do it sensibly? Connections aren't hugely expensive, but
>> they're not free, either.
JE> I suppose, but if it requires sending a keyspace param w/ each call,
JE> then it's not sensible. You waste far more overhead for that in the
JE> common case -- serializing, deserializing, checking that it's been
JE> authed -- than you gain from not having another connection in the
JE> uncommon one.
JE> I would be okay with being able to send a 2nd auth call to an existing
JE> connection to switch the "current" keyspace, similar to how rdbmses
JE> only have one active schema at a time.
How about:
login(Map<String, String> credentials) throws CassandraAuthenticationSecurityException
setKeyspace(String keyspace) throws CassandraAuthorizationSecurityException
and then all the existing API calls won't have a Keyspace parameter as
previously discussed. This works for everyone, I think, and separates
authentication from authorization nicely.
Ted
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Thu, 12 Nov 2009 10:49:59 -0600 Jonathan Ellis <jb...@gmail.com> wrote:
JE> On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo <jm...@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
>> > expensive.
>> Even if we can do it sensibly? Connections aren't hugely expensive, but
>> they're not free, either.
JE> I suppose, but if it requires sending a keyspace param w/ each call,
JE> then it's not sensible. You waste far more overhead for that in the
JE> common case -- serializing, deserializing, checking that it's been
JE> authed -- than you gain from not having another connection in the
JE> uncommon one.
JE> I would be okay with being able to send a 2nd auth call to an existing
JE> connection to switch the "current" keyspace, similar to how rdbmses
JE> only have one active schema at a time.
How about:
login(Map<String, String> credentials) throws CassandraAuthenticationSecurityException
setKeyspace(String keyspace) throws CassandraAuthorizationSecurityException
and then all the existing API calls won't have a Keyspace parameter as
previously discussed. This works for everyone, I think, and separates
authentication from authorization nicely.
Ted
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo <jm...@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
> > expensive.
> Even if we can do it sensibly? Connections aren't hugely expensive, but
> they're not free, either.
I suppose, but if it requires sending a keyspace param w/ each call,
then it's not sensible. You waste far more overhead for that in the
common case -- serializing, deserializing, checking that it's been
authed -- than you gain from not having another connection in the
uncommon one.
I would be okay with being able to send a 2nd auth call to an existing
connection to switch the "current" keyspace, similar to how rdbmses
only have one active schema at a time.
Re: Cassandra access control
Posted by Jonathan Mischo <jm...@quagility.com>.
On Nov 12, 2009, at 10:38 AM, Jonathan Ellis wrote:
> On Thu, Nov 12, 2009 at 10:23 AM, Jonathan Mischo <jmischo@quagility.com
> > wrote:
>> The problem I see with this is that you can't have a single
>> connection
>> accessing multiple keyspaces at once. I can think of some cases
>> where
>> having a single connection access and differentiate between two
>> keyspaces
>> would be advantageous, especially in certain kinds of reporting
>> applications. Otherwise, you force the creation and maintenance of
>> multiple
>> connection pools on the client side, which isn't as resource
>> efficient.
>
> Let's keep it simple. Forcing multiple connections from a purely
> hypothetical use case is a no-brainer tradeoff. Connections are not
> expensive.
>
Even if we can do it sensibly? Connections aren't hugely expensive,
but they're not free, either.
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Nov 12, 2009 at 10:23 AM, Jonathan Mischo <jm...@quagility.com> wrote:
> The problem I see with this is that you can't have a single connection
> accessing multiple keyspaces at once. I can think of some cases where
> having a single connection access and differentiate between two keyspaces
> would be advantageous, especially in certain kinds of reporting
> applications. Otherwise, you force the creation and maintenance of multiple
> connection pools on the client side, which isn't as resource efficient.
Let's keep it simple. Forcing multiple connections from a purely
hypothetical use case is a no-brainer tradeoff. Connections are not
expensive.
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Thu, 12 Nov 2009 10:23:21 -0600 Jonathan Mischo <jm...@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
JM> keyspaces would be advantageous, especially in certain kinds of
JM> reporting applications. Otherwise, you force the creation and
JM> maintenance of multiple connection pools on the client side, which
JM> isn't as resource efficient.
JM> This goes back to the concept we were talking about on IRC yesterday
JM> where a single user may have access to more than one keyspace. If you
JM> authenticate and the system authorizes access to multiple keyspaces,
JM> you should have access to them from the same connection, IMHO, since
JM> that's a pretty well established pattern.
It would also keep the API the same as it is now, just adding a login()
method. I am mildly in favor of allowing multiple keyspaces but
Jonathan Ellis seems to prefer the other variant and he made some valid
points too. I don't know if you guys want to vote or what, but I can
get started with the auth backend work regardless of the API direction.
Ted
Re: Cassandra access control
Posted by Jonathan Mischo <jm...@quagility.com>.
On Nov 12, 2009, at 10:06 AM, Jonathan Ellis wrote:
> 2009/11/12 Ted Zlatanov <tz...@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 function) but requires
>> an
>> extra authorization check every time a keyspace is given. Do we
>> expire
>> authorizations after a certain time?
>
> If this is going to 0.5 we should keep the existing API intact since
> we are very late in the 0.5 cycle (so, it's up to you if you need this
> in 0.5). But ultimately we want to drop the keyspace args in which
> case the no-auth-configured behavior is that you still send an auth
> method call but the auth accepts whatever it is given.
>
The problem I see with this is that you can't have a single connection
accessing multiple keyspaces at once. I can think of some cases where
having a single connection access and differentiate between two
keyspaces would be advantageous, especially in certain kinds of
reporting applications. Otherwise, you force the creation and
maintenance of multiple connection pools on the client side, which
isn't as resource efficient.
This goes back to the concept we were talking about on IRC yesterday
where a single user may have access to more than one keyspace. If you
authenticate and the system authorizes access to multiple keyspaces,
you should have access to them from the same connection, IMHO, since
that's a pretty well established pattern.
Re: Cassandra access control
Posted by Thorsten von Eicken <tv...@rightscale.com>.
+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 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
> keyspace you're authenticating to (this should be very simple and
> lightweight)
>
> Does that all make sense? The second note above is probably not
> strictly necessary for 0.5, but it streamlines the third note, since
> in 90+% of cases, you'll be working with a single keyspace and can
> save overhead by just authenticating to that single keyspace.
>
> On Nov 12, 2009, at 10:20 AM, Ted Zlatanov wrote:
>
>> On Thu, 12 Nov 2009 10:06:02 -0600 Jonathan Ellis <jb...@gmail.com>
>> wrote:
>>
>> JE> 2009/11/12 Ted Zlatanov <tz...@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 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. You want to keep allowing multiple keyspaces? That would
>>>> leave
>>>> the existing API intact (only adding a login function) but requires an
>>>> extra authorization check every time a keyspace is given. Do we
>>>> expire
>>>> 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
>> this
>> JE> in 0.5). But 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. If 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). Otherwise, no check is done. This keeps
>> 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. login() will
>> be required to specify the Keyspace regardless of whether authentication
>> is done or not. The only expected security exception here comes from
>> login(). Once 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
>> places in 0.5
>>
>> - implement that interface: provide a XML backend and a LDAP backend (no
>> JAAS). Also, a AllowAll backend will be provided.
>>
>> - add the configuration file stanza to point to the
>> authentication+authorization module to be used. Make AllowAll the
>> default auth backend there.
>>
>> - document all the changes
>>
>> Thanks
>> Ted
>>
>
Re: Cassandra access control
Posted by Jonathan Mischo <jm...@quagility.com>.
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
keyspace you're authenticating to (this should be very simple and
lightweight)
Does that all make sense? The second note above is probably not
strictly necessary for 0.5, but it streamlines the third note, since
in 90+% of cases, you'll be working with a single keyspace and can
save overhead by just authenticating to that single keyspace.
On Nov 12, 2009, at 10:20 AM, Ted Zlatanov wrote:
> On Thu, 12 Nov 2009 10:06:02 -0600 Jonathan Ellis
> <jb...@gmail.com> wrote:
>
> JE> 2009/11/12 Ted Zlatanov <tz...@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 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. You want to keep allowing multiple keyspaces? That would
>>> leave
>>> the existing API intact (only adding a login function) but
>>> requires an
>>> extra authorization check every time a keyspace is given. Do we
>>> expire
>>> 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 this
> JE> in 0.5). But 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. If 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). Otherwise, no check is done. This keeps
> 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. login()
> will
> be required to specify the Keyspace regardless of whether
> authentication
> is done or not. The only expected security exception here comes from
> login(). Once 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
> places in 0.5
>
> - implement that interface: provide a XML backend and a LDAP backend
> (no
> JAAS). Also, a AllowAll backend will be provided.
>
> - add the configuration file stanza to point to the
> authentication+authorization module to be used. Make AllowAll the
> default auth backend there.
>
> - document all the changes
>
> Thanks
> Ted
>
Re: Cassandra access control
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Thu, 12 Nov 2009 10:06:02 -0600 Jonathan Ellis <jb...@gmail.com> wrote:
JE> 2009/11/12 Ted Zlatanov <tz...@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 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. You want to keep allowing multiple keyspaces? That would leave
>> the existing API intact (only adding a login function) but requires an
>> extra authorization check every time a keyspace is given. Do we expire
>> 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 this
JE> in 0.5). But 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. If 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). Otherwise, no check is done. This keeps
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. login() will
be required to specify the Keyspace regardless of whether authentication
is done or not. The only expected security exception here comes from
login(). Once 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
places in 0.5
- implement that interface: provide a XML backend and a LDAP backend (no
JAAS). Also, a AllowAll backend will be provided.
- add the configuration file stanza to point to the
authentication+authorization module to be used. Make AllowAll the
default auth backend there.
- document all the changes
Thanks
Ted
Re: Cassandra access control
Posted by Jonathan Ellis <jb...@gmail.com>.
2009/11/12 Ted Zlatanov <tz...@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 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. You want to keep allowing multiple keyspaces? That would leave
> the existing API intact (only adding a login function) but requires an
> extra authorization check every time a keyspace is given. Do we expire
> authorizations after a certain time?
If this is going to 0.5 we should keep the existing API intact since
we are very late in the 0.5 cycle (so, it's up to you if you need this
in 0.5). But ultimately we want to drop the keyspace args in which
case the no-auth-configured behavior is that you still send an auth
method call but the auth accepts whatever it is given.