On Thu, 12 Nov 2009 10:06:02 -0600 Jonathan Ellis <[email protected]> wrote:
JE> 2009/11/12 Ted Zlatanov <[email protected]>: 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
