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.
