incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pratt <fairwinds...@gmail.com>
Subject Re: Per Document Filtering/Authorization
Date Fri, 03 Dec 2010 04:16:23 GMT
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.
>>
>

Mime
View raw message