I'd posted early on this mailing list my proposal. I think that per doc authorization should be controlled by the design documents, and per views authorization should be controlled too. validate_doc_access or validate_doc_read would be good to see here.
>From this point of view I can't find any benefits of separate auth database, is there someone who agree with me? 2010/12/3 Randall Leeds <[email protected]> > 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. > >>> > >> > > > -- Cheers, Fedor Indutny. Skype: fedor.indutny Gtalk: [email protected] Github: http://github.com/donnerjack13589
