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
<[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
