Re: Cassandra access control
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 jbel...@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 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 extra complexity for people who don't need it. Mark -- Anthony Molinaro antho...@alumni.caltech.edu
Re: Cassandra access control
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 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 jbel...@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( MapString, 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
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 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: Re: Cassandra access control
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:n...@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 + 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 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 eev...@rackspace.com wrote:
EE I'm thinking...
EE void login(1:required string keyspace, 2:optional mapstring, 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 mapstring, 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
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 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 eev...@rackspace.com
Re: Cassandra access control
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
+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 extra complexity for people who don't need it. Mark
Re: Cassandra access control
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 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 jak...@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
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 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 jak...@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
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: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 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
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 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
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 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
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 eev...@rackspace.com
Re: Cassandra access control
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 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 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 extra complexity for people who don't need it. Mark
Re: Cassandra access control
Got it. On Dec 2, 2009, at 4:42 PM, Jonathan Ellis jbel...@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 jak...@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 robin@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: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 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
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 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 eev...@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
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 mapstring, 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
eev...@rackspace.com
Re: Cassandra access control
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 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
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 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 eev...@rackspace.com
Re: Cassandra access control
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 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: Re: Cassandra access control
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: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 (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
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
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 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
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
Re: Cassandra access control
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 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
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 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 (was: bandwidth limiting Cassandra's replication and access control)
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 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 MapString,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. I'd really prefer to just keep that around in a threadlocal. There's no reason for a client to continue passing a token w/ each call that the server already knows. 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. The default should definitely be, don't break people who don't need the new feature more than necessary. So the default should be accept any client to any keyspace. -Jonathan
Re: Cassandra access control (was: bandwidth limiting Cassandra's replication and access control)
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 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. I'd really prefer to just keep that around in a threadlocal. There's no reason for a client to continue passing a token w/ each call that the server already knows. Another reason for this is it makes code a lot clearer. If you're looking for a keyspace argument, it gets confusing if it suddenly becomes a token, because if you don't know what the current connection state is (for whatever reason) or if authentication was previously done, you might not know what the argument should really be at the current moment. Yes, this can be solved programmatically, but why make things more complex than they need to be?
Re: Cassandra access control
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 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
+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 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 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
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 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 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
+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 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
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 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
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: 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 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 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
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 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(MapString, 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: Re: Cassandra access control
I would definitely like to see a simple file-space approach to begin with and then would investigate the need for LDAP binding. For that, I would start by using a CLI approach to LDAP searching and binding and use that as the performance test case against JNDI. Here are some references: http://www.openldap.org/ http://www.ietf.org/rfc/rfc2251.txt http://www.ietf.org/rfc/rfc2829.txt http://www.ietf.org/rfc/rfc2253.txt http://www.ietf.org/rfc/rfc1779.txt http://www.ietf.org/rfc/rfc2247.txt http://www.ietf.org/rfc/rfc1777.txt (v2) I will think about contributing but I need to shut down 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 control On Thu, 12 Nov 2009 08:23:51 -0800 Coe, Robin robin@bluecoat.com wrote: CR I agree. Getting into LDAP will open a can of worms, especially if CR the plan is to support Active Directory. There are a lot of RFCs on CR the subject of LDAP and Active Directory doesn't support them all. CR If LDAP is the plan, though, there needs to be support for ssl and CR tls, at a minimum. Would you like to contribute or point me to a library that makes this easier? There's probably code in JAAS I can use, too, even if I'm not using the whole library. Anyhow, the simple file-based backend will come first and perhaps that's all we need. Ted
Re: Cassandra access control
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 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(MapString, 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
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 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(MapString, 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: Re: Cassandra access control
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 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 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(MapString, 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 winmail.dat
