incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Cassandra access control
Date Thu, 12 Nov 2009 16:22:08 GMT
+1

2009/11/12 Ted Zlatanov <tzz@lifelogs.com>:
> On Thu, 12 Nov 2009 10:06:02 -0600 Jonathan Ellis <jbellis@gmail.com> wrote:
>
> JE> 2009/11/12 Ted Zlatanov <tzz@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
>
>

Mime
View raw message