cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Zlatanov <...@lifelogs.com>
Subject Re: Cassandra access control
Date Fri, 27 Nov 2009 17:02:51 GMT
On Wed, 25 Nov 2009 09:05:51 -0800 "Coe, Robin" <robin.coe@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


Mime
View raw message