[
https://issues.apache.org/jira/browse/COUCHDB-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909179#comment-14909179
]
Ben Liddicott commented on COUCHDB-615:
---------------------------------------
### 0. Summary
Convention + Filtered views + intersections = access control.
Start with a standardised-by-convention honour-system access control scheme,
which can be
implemented client-side as an honour system, or enforced by a proxy. Add a
system view
which gives the sd for each document.
Add filtered views to (COUCHDB-707) provide server-side support. Then add
intersections
(joins) with other filtered views so access control information is indexed.
Finally add ability to optionally apply access control filters transparently to
all views.
### 1. Honour System access control.
Extend the _security document to name additional groups than admin and member.
Specifically add "reader" (implicit read of all non-system documents) and
"restricted"
(no implicit access), and allow adding any number of arbitrary groups.
Extend the userCtx to contain the property "principals" being a list of DB
groups the user is in.
The user and the roles generate the list of principals at request time.
Therefore only principals
need to be consulted for
access control.
e.g. the
```
{
"db":"mailbox",
"name":"bob",
"roles":[
"cartographers"
],
"principals":[
"user:bob",
"role:cartographers",
"group:project X Admins"
"db:non-admin",
"db:restricted"
]
}
```
Each document can have a new system property, _sd. This can be consulted to
discover desired access.
An absent _sd means anyone may access. An empty _sd means only admins.
Otherwise as described by the sd.
Levels are read-only, and full access (including delete).
_sd:{
"user:bob":"rw",
"role:cartographers":"r",
"group:project X Admins":"rw"
}
We now have a client-side honour system access control.
### 2. Allow filter functions to be used for views and for document reads.
This would allow users to specify a filter function which implemented
access control to see only parts of the view they wish to see.
The filter function would be applied before the reduce step. Queries without
a filter function would proceed as at present. Queries with a filter function
will
On the honour system, this would be slow for views because it requires
reading the document to retrieve the sd, unless the sd were output in the value.
Need to ensure multiple filter functions can be used together.
### 3. Allow intersection queries when querying views. (Yes, a bit like a join.)
Specify multiple views (potentially each with their own filter).
The output of the first view is the only one returned, but it is filtered by
only accepting the document IDs
which are produced by the other views.
### 4. Create a new system view _doc_sd which emits an entry for each document
_sd entry.
If the _sd is empty, it will emit the implicit equivalents
"documentID","db:readers","r"
### 5. Now we can (if configured) implement access control by implicitly
querying _doc_sd
for intersection with the usrCtx.groups as keys.
### 6. Write access control can, as now, be implemented by the validation
function.
### 7. Protection of namespaces from pollution by downlevel users can be
provided by
validation functions. These would consult a _namespace_sd document which would
contain
prefix to _sd mappings.
> Role, ACL and Ownership Checks
> ------------------------------
>
> Key: COUCHDB-615
> URL: https://issues.apache.org/jira/browse/COUCHDB-615
> Project: CouchDB
> Issue Type: New Feature
> Environment: Ubuntu 9.10 64bit
> Reporter: Alexander Trauzzi
>
> It would be nice if CouchDB had a comprehensive offering for varying levels
> of access to documents and databases.
> Here are some ideas:
> o User lists are stored in the database, per database.
> o Roles and role membership are stored in the database, per database.
> o ACLs are stored in the database, per database.
> o CouchDB can use ACLs to store and simplify permissions for internal
> functionality (manage the db, manage users, add roles, add users to roles,
> etc...)
> o CouchApps can take advantage of the ACLs to support login/logout and
> arbitrary business rules as needed.
> o A simple API can be made to conduct role, ACL and ownership checks.
> I suppose there is some theory and discussion behind determining whether
> users, roles or both are stored in ACL rules. Also, something worth
> discussing is whether the checks are automatically performed by couchdb, or
> if views are to be performing checks prior to emitting data. Or both...
> Building all this into CouchDB would mean that it has a mechanism for complex
> applications to be developed. Ones that mandate privacy and other visibility
> concerns.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
