On Wed, 25 Nov 2009 09:05:51 -0800 "Coe, Robin" <[email protected]> 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
