cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject Re: Cassandra access control
Date Thu, 12 Nov 2009 16:50:41 GMT
frameworks that do that should be shot.

On Thu, Nov 12, 2009 at 10:48 AM, Thorsten von Eicken
<> 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 <>
>>> wrote:
>>> JE> 2009/11/12 Ted Zlatanov <>:
>>> 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

View raw message