incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: Per-DB Auth Ideas and Proposal
Date Tue, 08 Sep 2009 19:40:27 GMT
On Mon, Sep 07, 2009 at 11:50:11PM +0100, Jason Davies wrote:
> 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.

I'm not sure what's meant by that last sentence.

One of the nice things about CouchDB is the 'virtualisation' provided at the
database level - individual databases are self-contained, and a database can
be thought of as an individual application or application instance.
Therefore it certainly makes sense either to store the users within the
database instance, or to be able to configure each database instance to find
its user information elsewhere (e.g. point to a specific LDAP database), or
to allow certain databases to be fully open whilst others are protected.
ISTM that this should be an attribute of the database itself, not of a
global set of "users".

However there's obviously also a need for authentication for top-level
operations (e.g. _restart) and to create and delete databases. I consider
this level corresponds to "couchdb node administrator" rather than "database
user", and I'd be happy to see that still defined as an authentication
module in the .ini file (which could in turn be a module which refers to a
CouchDB database, of course, but might also be an LDAP database or a static
list of users, especially for bootstrapping)

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

For me, an important use case is to be able to restrict access to _design
docs without resorting to proxies.

> 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/".

I think this requirement goes away if each database has its own
authentication/authorization configured. But as you say, you potentially
want to extend authorization to the path level, or to each document/view
somehow.

Just my quick thoughts.

Brian.

Mime
View raw message