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