Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 209.85.222.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=wxA0QIe1sdMRkJdEfb7niMxtHQK+fNW7zxpnO3IOloBqYix5xP9e8iv9jnhBeRdayr
         TCAMn5y7/7A7ozoESTRW6TlfWM57YkadRuePO5w1CBLpBQjb0NzI6Nor5wcFRcUhS4Uy
         IbJ5w5AqhElGC4g87jm09G88cPMp+PKVO2ynw=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <4B509D67.8040307@canonical.com>
References: <594289661001131435h70a40f92r5dcfeadf757c3461@mail.gmail.com>
	 <e282921e1001131453i316e9aacra2eabcc1d5907ab4@mail.gmail.com>
	 <4B509D67.8040307@canonical.com>
Date: Fri, 15 Jan 2010 09:30:00 -0800
Message-ID: <e282921e1001150930h2a8c0fd5t8bad7536b88cb755@mail.gmail.com>
Subject: Re: Changing the default _auth validation function
From: Chris Anderson <jchris@apache.org>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 15, 2010 at 8:52 AM, eric casteleijn
<eric.casteleijn@canonical.com> wrote:
>> 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 Couch=
DB,
> and it's authorization model may be of interest (In no way am I suggestin=
g
> 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 si=
nce
> 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, the=
y
> 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 ther=
e)
> a simplified version of which could look like:
>
> permissions: add users | add content | modify content | read content
> roles:
>
> admin =A0 =A0 =A0 =A0 =A0 =A0 X =A0 =A0 =A0 =A0 =A0 =A0X =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0X =A0 =A0 =A0 =A0 =A0X
> editor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 X =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0X =A0 =A0 =A0 =A0 =A0X
> author =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0X =A0 =A0 =A0 =A0 =A0X
> anonymous =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0X
>
> In practice there are many more permissions, and developers can define th=
eir
> 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 th=
e
> site.

Thanks for the thoughtful post. I think for simplicities sake we
should keep our access control at the server or db level, but you've
given a good description of what db-level permissions could look like.

I'll have to think more about this. One option is to build the
security obj from a view request. I think that might be dangerous...

The key here is that we want some per-db assignment of roles, and the
problem is that if those roles are assigned from a single object it'll
start to be too big for memory, when there are lots of users.

The sensible thing seems to be to have some ability to set roles on
the userCtx in a per-database way, that can handle lookups from
usernames somehow.

Chris

>
> There are two special roles that are system defined which do have a meani=
ng
> 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 woul=
d
> 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 grant=
ed
> to a user for a bunch of databases that are grouped under a particular ur=
l,
> 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 authorizati=
on
> it still makes a lot of sense to me.
>
> Of course in the case of CouchDB the exact same thing can't be done, beca=
use
> 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.
>
>


--=20
Chris Anderson
http://jchrisa.net
http://couch.io