incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fedor Indutny <fedor.indu...@gmail.com>
Subject Re: Per Document Filtering/Authorization
Date Fri, 03 Dec 2010 04:47:14 GMT
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 <randall.leeds@gmail.com>

> 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 <fairwinds.dp@gmail.com> 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 <chad@mgproducts.com> 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 <fairwinds.dp@gmail.com>
> 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: fedor.indutny@gmail.com
Github: http://github.com/donnerjack13589

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message