couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Goodlad <da...@goodlad.ca>
Subject Re: Reader ACLs
Date Mon, 18 Jan 2010 12:59:00 GMT
On Mon, Jan 18, 2010 at 8:31 PM, Brian Candler <B.Candler@pobox.com> wrote:
>> http://github.com/jchris/couchdb/tree/readeracl
>
> I have tried out the readeracl branch, and I have the following
> observations.

[snip]

My biggest 'take away' from all of those observations is a feeling
that I've had for quite some time, that security should be the
responsibility of the application in a given database. That, to me,
means managing it through regular and/or design documents. I know this
doesn't fit the existing scheme; but the existing scheme seems quite
limiting and somewhat naive of many potential applications.

The idea that security (authorization, maybe not authentication) can
be managed by the app itself, with some combination of regular and/or
design documents, seems to fit very well with the existing idea of
design documents. Authorization for writing is already being handled
by convention in the validation function, which is part of design
docs, so why not take that idea further and extend it to reading?

App developers should be free to implement a wide range of security
mechanisms without having to resort to putting software (a proxy) in
front of couchdb. Couch should take care of authentication in a
standard way (the cookie auth via lookups on the _users database or
extensions like oauth etc), then step back and let the app developer
decide how to do authorization for both read and write operations.

I've got a few ideas for how this could be implemented.

First, db-wide read/write/admin access could be determined via a view.
The view would would emit rows with usernames as keys, and data to be
used for authorization as the value (or an _id/_rev pair, which would
use the existing functionality for including/referencing other docs).
For example, a reader view's map function could look something like
this:

function(doc) {
  if(doc.type == 'user' && !doc.banned) {
    emit(doc.name, doc.roles);
  }
}

The existing validate functions would be given a new parameter (in
place of the 'security object' as previously discussed) containing the
value from the view:

function(newDoc, oldDoc, userCtx, userData) {
  if(newDoc.type == 'article' && userData.indexOf('editor') == -1) {
    throw({forbidden: "Only editors can change articles"})
  }
}

These examples use an array of roles, but any data could theoretically
be passed around, allowing great flexibility.

I'm not sure of the performance implications of such a scheme, but
with some reasonable cacheing thanks to the use of views, I'd hope
that it would not have much of an impact.

What do you guys think?

Dave

Mime
View raw message