couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <>
Subject Re: Per-DB Auth Ideas and Proposal
Date Wed, 09 Sep 2009 02:06:07 GMT

On Sep 7, 2009, at 5:50 PM, Jason Davies wrote:

> Hi all,
> There have been sporadic discussions about various granularities of  
> authorization.  The most simple level to tackle is per-db  
> authorization.  What follows is a summary of discussions and ideas  
> so far.
> I should point out that this is primarily to flesh out the default  
> authorization modules that address the needs of the majority of  
> users.  We probably will have an authorization_handlers settings,  
> analagous to authentication_handlers, allowing custom authorization  
> modules to be used.

I think it would be common for there to be a fairly high  
initialization cost in loading and preprocessing authorization data  
for more complex authorization schemes, so you'd want something like  
the gen_server behavior and message passing on authorization for the  
generic authorization hook.

> 2. What types of operations do we need to support?  I think the  
> majority of users will only care about being able to make particular  
> databases read-only, read/write, or write-only (not sure about the  
> latter one).

As long as the authorization hooks are generic enough to support  
content-aware authorization, I'm not particularly concerned with the  
details of a specific authorization module.  My main concern is that  
the hooks might be designed only to meet the needs of a specific  
authorization module and would not be able to handle more generic cases.

> 6. Future work: thisfred suggested that the pattern-matching could  
> be extended to the full URL instead of just the database name.  This  
> seems like a simple way to extend authorization.  Of course, it's  
> dependent on a particular node's URL mappings (these can be changed  
> in the .ini).  This then brings up the question of what the  
> operations should be, it would make the most sense to let them be  
> HTTP verbs, so that one could restrict access to certain URLs to  
> being only GET and HEAD for example.  This seems a bit too tied to  
> HTTP for my liking, but I guess CouchDB is very much a RESTful and  
> therefore HTTP-reliant database.  Any further ideas would be welcomed.

I'd like to see call outs to authorization in couch_db around any read  
or write to the underlying store.  If the authorization is HTTP  
request based, then to restrict access to particular piece of info,  
you need to restrict the document GET, any queries or lists might  
reveal the info, etc.  Then if some later version of CouchDB adds a  
new http request, previously controlled might be exposed.  I do  
believe it is valuable to be able to restrict particular http request  
methods, but it isn't sufficient.

On Sep 8, 2009, at 5:41 PM, Adam Kocoloski wrote:
> So, after giving this some thought I'm partial to the idea of Access  
> Control Lists. Instead of directly granting privileges on databases  
> in the users DB, we'd store an ordered list in the DB in a special  
> document that would allow|deny requests that match a rule.  For  
> instance, if I wanted to make a read-only DB where only I could  
> access the _design documents I could upload a document like
> {
>    _id: "_authorization",
>    _rev: "1-1340514305943",
>    _acl: [
>        {"access":"allow", "role":"kocolosk", "method":"*",    
> "path":"*"},
>        {"access":"deny",  "role":"*",        "method":"*",    
> "path":"_design*"}
>        {"access":"allow", "role":"*",        "method":"GET",  
> "path":"*"},
>        {"access":"deny",  "role":"*",        "method":"*",    
> "path":"*"}
>    ]
> }
> The rules in the ACL array are applied in order, and the first rule  
> to match wins.  Here I've assumed that my user has a corresponding  
> role, like a UNIX group.
> I explicitly listed the deny rule at the end, but we could make that  
> the default if we wished.  CouchDB has historically been pretty  
> open, but sysadmins would probably prefer it if things were secure  
> out-of-the-box.  I think the right default setting will become clear  
> during the implementation.

I was thinking that a transliteration of XACML to JSON would be a good  
approach ( 

View raw message