incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Zlatanov <>
Subject Cassandra access control (was: bandwidth limiting Cassandra's replication and access control)
Date Thu, 12 Nov 2009 16:06:30 GMT
On Thu, 12 Nov 2009 07:28:29 -0800 "Coe, Robin" <> wrote: 

CR> I'm not sure JAAS is the way to go when implementing a performant
CR> authentication/authorization service.  This is what threw me off in
CR> the first place.


CR> So, my concern is, and has been since this discussion started, is
CR> that Cassandra should not be performing this work.  I suggest that
CR> the Thrift connection is opened with credentials passed in, which
CR> Cassandra authenticates to.  Even this overhead is not something I
CR> would want to incur on every connection, so I would use a connection
CR> pool, with the connections pre-authenticated to a single account
CR> that's appropriate for my application.

It sounds like JAAS is a bad idea.  I'll use a modular auth system then,
with two simple implementations (XML file and LDAP) at first.  The XML
file will hold account passwords (one-way hashed) and authorizations.
The Apache Commons Configuration library can parse the XML file for us.
With LDAP, we'll use the property file for authorizations only.  We can
optimize the LDAP backend if needed.  Sounds good?

CR> Basically, the authentication on the Cassandra side needs to be
CR> lightning fast and performing LDAP lookups from Cassandra as each
CR> Thrift socket is opened will definitely impact performance.  

This depends on the application.  Mine, for example, use few sockets and
keep them open for a long time.  Keep in mind this only happens if the
user wants to login, too.  Unauthenticated access will not require any


View raw message