couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pratt <>
Subject Re: Per Document Filtering/Authorization
Date Thu, 02 Dec 2010 02:33:54 GMT
I am all for document level security as I don't want a raft of small
databases to manage but rather a single large store. I am also
interested in an integrated solution with what we already have.

A possible solution is one I am familiar with from another framework.
My thought is that we might wish to implement a special _authorization
database (or give it some flexible name similar to _users) that is not
under MVCC rules. The purpose for the _authorization db is to provide
a mapping of keys to a value containing  a list structure providing
one or more access control entries. I have often thought a document
ought to have a _type by default. Such an attribute (whatever it may
be called) would eliminate the need for everyone to add a type
attribute which is a common scenario for document filtering. If _type
is null, _authorization is not looked up.

In this scenario, a key in the _authorization database corresponds to
the _type. _authorization could use a naming convention to _users that
makes it special.

The essential elements of a document in the _authorization database
would be _id that identifies the _type and an access control list
attribute that provides the access control list. An access control
list contains entries. Each entry contains an action (either Allow or
Deny) that we want to take when the access control entry matches and
Role or Name. Readers and Admins already have implied permissions.

The way it works it that the acl would be consulted and each access
control entry evaluated to determine whether the principal (Role or
Name) has permission (resulting in an evaluation to True or False).

Our authentication is already pluggable so this type of access control
list, which is already a familiar pattern could be a decent way to get
document level authorization.

View raw message