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.
