frameworks that do that should be shot.
On Thu, Nov 12, 2009 at 10:48 AM, Thorsten von Eicken <[email protected]> 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 <[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 >>> >> >
