incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From eric casteleijn <eric.castele...@canonical.com>
Subject Re: Changing the default _auth validation function
Date Fri, 15 Jan 2010 16:52:55 GMT
> This sounds reasonable, but maybe we can make it easier.
>
> You could almost model the manager as a db_admin, but you probably
> don't want them editing design documents. So what you need is a set of
> roles that apply to particular users, in the context of a particular
> database. Maybe it makes more sense to store the db-roles within the
> db itself?
>
> I think this is the use case for the security object. (Just a 4th
> argument to the validation function, which is a document loaded from
> the database the validation runs from)
>
> We should ask Damien to weigh in on the _namespace to use for the
> document (should it be local?), and how to store the info.
>
> Glad to have you on the list, Dave.

I'm aware I'm running the risk of becoming that guy that always brings 
up Zope, but I think that platform has some interesting parallels with 
CouchDB, and it's authorization model may be of interest (In no way am I 
suggesting CouchDB copy it outright, but I think it may contain some 
interesting ideas.)

Zope isn't partitioned into multiple databases the way CouchDB is, but 
since any subtree can define its own users, permissions and roles, it 
might as well be, for authentication/authorization purposes.

Users defined on a subtree *or higher up* can be assigned any number of 
roles for that subtree. (basically the equivalent of couch's users db 
can be dropped in at any part of the content tree.)

Permissions and roles are orthogonal: roles have no inherent meaning, 
they are just a way of mapping permissions to parts of the site 
conveniently.

On any subtree of the site, one can manipulate a matrix of roles x 
permissions, (if the authenticated user has the permissions to do so 
there) a simplified version of which could look like:

permissions: add users | add content | modify content | read content
roles:

admin             X            X                X          X
editor                         X                X          X
author                                          X          X
anonymous                                                  X

In practice there are many more permissions, and developers can define 
their own, and check for them in validation functions.

Application developers or site managers can define their own specialized 
roles, and grant the needed permissions to them for a specific part of 
the site.

There are two special roles that are system defined which do have a 
meaning and aren't assigned to users in the user administration, and 
those are anonymous and authenticated.

I think the discussion here is heading in a similar direction, but I 
would once again like to suggest keeping in mind the possibility of 
doing this not just per database, but per url sub path, so that 
permissions can be granted to a user for a bunch of databases that are 
grouped under a particular url, rather than server wide or per database 
only.

Zope 2's implicit 'acquisition' model, where things were looked up in a 
particular folder and in the case they were not found, in any containing 
folder, all the way up the tree, was an interesting but ultimately 
failed experiment in the case of content, but for authentication and 
authorization it still makes a lot of sense to me.

Of course in the case of CouchDB the exact same thing can't be done, 
because if you have:

server/foo/bar
server/foo/baz/qux

you can't place an authorization mapping at foo, because foo doesn't 
actually exist, so in the end you have to define things server global, 
or in the database itself. I still think it would be a very useful thing 
to be able to set permissions for server/foo/* in the global users db.


Mime
View raw message