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: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)
Date Sat, 06 Feb 2010 09:58:56 GMT
A thought.

The current security model requires you spread information in three places:
_readers (has access to database); _security (for controlling updates);
_admins (can update security and ddocs)

What if this was replaced by a single resource, _security, structured like
this?

   {
     "names":{
       "foo":[],
       "bar":["_admin"]
     },
     "roles":{
       "baz":["doctor"]
     }
     "otherstuff"
   }

You get reader access if your name or role appears as key in the relevant
section, regardless of the value.  So [] means reader only.  You get admin
access if the value contains "_admin". Other rights are available for the
application to use, and may affect validate_doc_update.

The reasons I propose this are as follows:

1. it's extensible without having to change the DB structure again
2. application-specific rights can be administered in the same way as
   couchdb system rights
3. futon can display this clearly - a list of names and a list of roles,
   each with their rights shown next to it
4. a hash key is quicker to look up for access control than an array scan

However it retains the current fundamental design, which is that the rights
are stored in a resource within the database, which is not a document.

Thoughts?

What I've really done is to flip things around, so that

    "readers":["name1","name2"]
    "admins":["name3"]

becomes

    {"name1":["reader"], "name2":["reader"], "name3":["admin"]}

But doing that also makes it easier to add a future auth model where rights
are stored in a more scalable way (e.g. as separate user documents or in an
external LDAP database), where such information is keyed by username or
role.

Regards,

Brian.

Mime
View raw message