A separate database is a bad idea IMHO. Whatever solution to per-document filtering we come up with should allow for the CouchApp-style database-as-application paradigm where one expects to get a fully working application by replicating a single db.
On Thu, Dec 2, 2010 at 23:16, David Pratt <[email protected]> wrote: > Hi Chad. Yeah, reason for _type was that it fits with what most folks > are doing already - no changes. Putting security in a separate > _authorization database isolates it so there is no additional overhead > for those that do not wish to implement it (again, no changes). > Second, being a special database, no MCVV overhead and potential to > load into a cache (since it is small) and lookups ought to be fast and > inexpensive. ACLs are also pervasive, simple and easily understood. > Lastly, it also integrates with Names and Roles that we are already > using with inherent permissions associated by Admin and Readers > groups. In my previous note I showed how easy it would be to isolate a > type to a user or role (where one or more entries can effectively > limit or isolate access). > > Personally, I think a separate function per doc adds substantial > overhead. Each doc is susceptible to versioning. The overhead of a > single key per document _type in an _authorization database is much > less by an order of magnitude since the number of types is small > comparatively to documents. As a result, an _authorization database > would be quite small - even in relation to the _users database. I am > thinking that it ought to be possible to implement with minimal logic > as well. > > On the issue of overhead, consider the difference between a database > containing 10 million versioned docs - each having a security method > compared to an _authorization database having a fast lookup of types > that checks access control entries. I would be surprised that an > _authorization database would contain any more than 100 records (where > each doc corresponds to a _type. Each type only needs to possess a > single _acl attribute containing a list of perhaps one to three items > to evaluate. Being so small, caching for lookups seems a reasonable > way to get speed. The notion of caching fits well with the scale we > want from a large sharded data stores. > > I could see a need to consider a naming strategy in _authorization > that could provide isolation of acls on a per database basis. This > would not make things any more complicated as the database we are > working with is already part of the context. Editing an acl would be > no different for the fact you would be concerned with a record for a > specific database. > > Anyway, is good to talk about ideas since this is ultimately the only > way anything may be eventually realized. > > Regards, > David > > > On Thu, Dec 2, 2010 at 6:43 PM, Chad George <[email protected]> wrote: >> One important use case where a validation function works better is when the >> same document "type" needs to be only accessible by certain users (like the >> document's creator). >> >> I'm not certain what we gain by having a separate _authorization database >> over just putting that information in a design document. >> >> Your document "_type" field is conceptually similar to my original idea of >> attaching the access validator to a document to give it a type. A more >> generic type field that could be used for view filter is probably better >> though and might relieve previous objections to directly assigning security >> functions on the data. >> >> Perhaps we could combine both ideas: >> - add an official "_type" field to the document API since its pretty common >> anyway. >> - design documents have a _access field which is a dictionary associating >> _types for that database with either a whitelist/blacklist ACL or a function >> that is evaluated with the request context and document. >> >> - Chad >> >> On Thu, Dec 2, 2010 at 12:14 PM, David Pratt <[email protected]> wrote: >> >>> > which is already something most folks do for filtering views etc. If >>> > there is no entry in _authorization database, the data accessible to >>> > the extent that we have any Readers for database as it is now. >>> >>> sorry typo - last bit should have read .. >>> >>> the data would be accessible to the extent that we have any Readers >>> for database as it is now. >>> >>> To add to above, it might be good for the system to have a special >>> entity named "ALL" where access to everyone is not implied by the >>> absence of record in _authorization for the _type but could be made >>> explicitly if desired. >>> >> >
