incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Davies <>
Subject Per-DB Auth Ideas and Proposal
Date Mon, 07 Sep 2009 22:50:11 GMT
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  

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.

1. Where are the permission "objects" themselves stored?  The  
permissions determine which users can do what with each database.  I  
think storing these in the per-node users database (called "users" by  
default) makes the most sense.  We are talking about per-db auth so it  
wouldn't make any sense to store this information in the affected  
databases themselves.

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).

3. How do we implement these operations using the existing  
user_ctx{name=..., roles=[...]} object?  I don't think we necessarily  
need to set any special roles, although this was my initial thought  
e.g. ['_read', '_write'] on a per-db basis.  As authorization is a  
separate module, we can simply pass the appropriate permission (read  
and/or write) through when opening the db internally in the httpd db  
handler function.  The db-opening function will then need to throw an  
error if writes are attempted and it is in read-only mode.  Using  
actual roles is potentially more elegant, as custom roles could also  
be set using the permission objects and implementation might be easier.

4. One use-case we need to bear in mind is being able to grant/deny  
access to sets of databases at a time.  One way to do this would be to  
allow patterns to be specified, for example:

     "_id": "foo",
     "type": "permission",
     "username": "jason"
     "match": "jason/*",
     "operations": ["_read"]

This would grant the user "jason" read-only access to any database  
that has the prefix "jason/".

5. Permissions per roles vs permissions per users?  Although the above  
example specifies access for a particular user, it might be more  
elegant and efficient to do this per role instead.  If per user is  
needed this can be done by giving the user a special role unique to  
them.  If a user has multiple roles then we would take the union of  
the resulting permission set.

5. Default settings: we already have the require_valid_user setting,  
which forces a node to authenticate users.  We would need to support  
certain access permissions for non-logged-in users i.e. anonymous  
users.  This could be done using a special "_anonymous" string in the  
permission to override the default, which would probably be read/write  
for everyone as it is now.

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.

Jason Davies

View raw message